El Cedazo

En la entrada anterior vimos cómo se fueron definiendo las técnicas de modelización que permitieron formalizar la resolución del Diseño Funcional y Técnico de las Aplicaciones, dado que la formalización de la Programación había sido realizada unos años antes, mediante la técnica de Programación Estructurada, y cómo, a partir de mediados de los ochenta, comenzó su difusión generalizada.

Vimos también que a principios de los ochenta había ya algunas Metodologías de Desarrollo por ahí danzando, y cómo adoptaron estas técnicas de modelización rápidamente para formalizar las Fases de Análisis y Diseño. Y también cómo algunos productos informáticos servían para ayudar al desarrollador (hablando con propiedad, al programador) a realizar su trabajo más rápidamente.

Pero estas técnicas de modelización, que estaban muy bien, seguían teniendo un problema: la documentación se generaba con lápiz y papel, lo que originaba un par de problemas: primero: que realizar cambios a un dibujo hecho a boli durante el mantenimiento de las aplicaciones no era muy práctico, precisamente (o sea, que casi nadie lo hacía, vaya), y segundo, que… ¡el papel lo aguanta todo! Allí puedes pintar una relación de 1:n entre un Proceso y una Relación n:m… y el papel no protesta lo más mínimo.

Por lo tanto, sin el concurso de una herramienta informática que se asegure de que el modelo que se diseña es factible y de acuerdo a la técnica, no es posible afirmar que el modelo es correcto.

Y la única manera conocida de modificar una y otra vez un cierto modelo, tanto durante su concepción, como luego, durante la vida de la Aplicación, y que en todo caso lo que está allí representado sea siempre correcto desde el punto de vista de la técnica, es guardarlo en formato electrónico, y gestionarlo mediante una herramienta informática.

En una palabra, si se quería que todo esto fuera de verdad aplicable, se necesitaban herramientas CASE, y de ellas trata esta entrada.

Como la serie va teniendo ya bastantes capítulos, aquí tenéis el enlace a todos los artículos, para poder acceder a ellos a vuestra conveniencia.

Supongo que ahora esperáis que empiece a contaros qué herramientas CASE había, cómo funcionaban, etc.

Pues sí, pero un poco más tarde. Comprendedlo, son manías de anciano…

Porque lo primero que quiero reflexionar con vosotros es el significado profundo que la implantación de este tipo de Herramientas (junto con las inseparables Metodologías de Desarrollo), tienen en el trabajo del Departamento de Desarrollo, bueno, en realidad, de todo Proceso de Datos. Voy a hablar de la inescrutable filosofía que está detrás de todas estas técnicas y herramientas, y de la que yo jamás he oído hablar a nadie (salvo a mí mismo, claro). Voy a contaros un secreto…

¿Qué es, en realidad, una Metodología? Una serie ordenada de tareas y procedimientos, junto con las técnicas asociadas, que permiten a los profesionales del Desarrollo cumplir con su trabajo (escribir software y luego implantarlo y mantenerlo funcionando, mayormente) con la máxima calidad y eficiencia, en el menor tiempo posible, y siempre con el menor coste posible. ¿Sí?

Y… ¿para qué sirve una Herramienta CASE? Para ayudar a realizar estas tareas y procedimientos con un soporte informático que nos ayude, por un lado, a seguir rigurosamente el Método seleccionado, y por otra, a asegurar en todo caso y tiempo la corrección formal de nuestro trabajo, la salvaguarda de la información, su mantenibilidad en el tiempo…

.

Pero… ¿Con qué objetivo nos pagan nuestros generosos salarios nuestros patronos, cuál es el beneficio que los accionistas de nuestra empresa esperan obtener a cambio de nuestro trabajo, y de nuestro sueldo? ¿Cuál es, en realidad, el trabajo de nosotros, los informáticos? …Porque no es para “Escribir Programas brillantes”, no. No es tampoco para “Diseñar Aplicaciones Chulas”, ni mucho menos, como ya sabéis, ni para “Utilizar las Herramientas más novedosas”, en absoluto.

A nosotros nos pagan para proporcionar a nuestros Usuarios (el resto de la empresa) una serie ordenada de tareas y procedimientos, apoyados por un soporte de software informático, que les ayude a, por un lado, seguir rigurosamente los procedimientos de trabajo, y por otro, asegurar la corrección formal de la información crítica de la empresa, su salvaguarda, la capacidad de recuperación ante errores, su mantenibilidad en el tiempo…

Volved a leer un par de párrafos más arriba, si os place, donde describía grosso modo para qué servían las Metodologías. ¿Veis alguna coincidencia?

¡Exacto! Con el advenimiento de las Metodologías y de las Herramientas CASE, lo que estaba ocurriendo era, de facto, que estábamos informatizando al Departamento de Informática. Ni más ni menos.

¡Sólo que no lo sabíamos! O no queríamos saberlo, quizá.

A mí siempre me ha parecido muy curiosa esta esquizofrenia colectiva de nosotros, los informáticos: nos hemos opuesto sistemáticamente a que alguien nos mecanice nuestro trabajo, cuando eso es precisamente lo que hacemos nosotros continuamente… o quizá es, precisamente, por eso mismo.

Es decir, los pasos lógicos que seguimos cuando nos acercamos a un Usuario cualquiera (digamos, el Departamento de Riesgos, o el de Contabilidad…) para poner en marcha una Aplicación para él, siempre han sido, más o menos:

a) Estudio del Sistema Actual: En él nos informamos de cómo trabaja ese Departamento, qué datos maneja y qué procesos realiza, qué interfaces tiene con el resto de Departamentos, y, en definitiva, cuáles son sus necesidades.

b) Diseño del Sistema Propuesto: En base a la información obtenida anteriormente, realizamos el Modelo Tecnológico, el Modelo de Datos que soportará su negocio, el Modelo de Procesos, identificando oportunidades de mejora, etc, etc. Se seleccionan las herramientas hardware y software que se necesitarán para dar soporte al futuro Sistema, se establecen tareas, plazos…

c) Realización del Sistema: Una vez aprobado lo que se quiere hacer, pues se hace (incumpliendo los plazos, como es tradición), se implanta (con problemas, como siempre), se forma al usuario en su uso, se da soporte, y luego se mantiene por los siglos de los siglos, amén.

.

Por consiguiente, si lo que deseamos es mecanizar al Departamento de Informática, lo lógico es aplicarnos la misma medicina que nosotros aplicamos a nuestros usuarios: Estudio del Sistema Actual, Diseño del Sistema Propuesto y Realización del Sistema, ¿no os parece?

Pues no.

No conozco ni un solo caso en España (y supongo que tampoco habrá muchos por ahí fuera, si es que hay alguno) en que esto se hiciera así, es decir, con amplitud de miras, sabiendo cuál es el objetivo final, y tomando las decisiones pertinentes. La implantación de Metodologías, Herramientas y Técnicas en Desarrollo, y en todo Proceso de Datos, se fue haciendo “a trocitos”, de forma parcial, y en muchos casos forzado por la presión mediática y de las consultoras: llegó un momento, a fines de los ochenta, en que “si no ponías un CASE en tu vida, eras un neanderthal”, así que se adquirieron herramientas, se adoptaron métodos, se enseñaron técnicas… pero sin un Programa Director que nos indicara de dónde veníamos, a dónde íbamos, ni, desde luego, cuáles eran los objetivos finales a obtener, cuál era la luz al final del túnel.

No hubo, en definitiva, metodología alguna que usáramos para la selección de nuestra metodología, ni de nuestras magníficas Herramientas CASE… y el resultado es que, diez, doce o quince años después de aquéllos momentos cruciales en nuestra profesión, no queda prácticamente nada. Apenas hay alguna gran empresa española que siga hoy en día utilizando alguna de las Metodologías, Técnicas y Herramientas entonces seleccionadas, tras el arduo trabajo de prospección del mercado, prueba, y, desde luego, religioso pago a los proveedores que entonces se hizo.

Siempre hubo una enorme reticencia (resistencia, diría yo) al cambio por nuestra parte. Nosotros, los adalides del cambio, siempre que sea aplicado a los demás, nos negábamos sistemáticamente (y nos seguimos negando, por lo que sé) a cambiar nuestros usos y costumbres, a aceptar que alguien, aunque sea uno de nosotros mismos, venga a decirnos cómo hacer mejor nuestro trabajo. Porque… somos especiales, raritos, únicos, nuestros Sistemas son sofisticadísimos, igual que nosotros mismos lo somos, nuestras corbatas son las más bonitas, y bla, bla, bla… ¡Venga ya!

La verdad pura y dura es que hemos fracasado rotundamente en mecanizar al, supuestamente, Departamento más fácil de mecanizar: Nosotros mismos. La versión 1.0 nos ha salido rana. Nunca funcionó de verdad, ni siquiera cuando estaba recién implantada. Ayudó poco y entorpeció mucho, o la entorpecimos nosotros, que también. Y feneció de inanición.

Ahora estamos en plena versión 2.0: cambio de paradigma (Orientación a Objetos), cambio de Herramientas, de Tecnología… ¿Seremos esta vez capaces de dotarnos a nosotros mismos de un Sistema Informático que cumpla con las expectativas de cualquier Sistema Informático de los que amorosamente entregamos a nuestros Usuarios? La respuesta está en vuestras manos, amigos. Y conmigo no contéis esta vez, que yo ya fracasé cuando fue mi turno.

.

Y… después de esta sesuda (y sí, un poco amarga) reflexión, voy a contar lo que estabais esperando: cómo fue el baile de las herramientas CASE a finales de los ochenta y principios de los noventa.

Ya dije en la entrada anterior que había alguna herramienta a mediados de los ochenta (PACBASE, de CGI y Maestro, de Softlab, eran las más importantes y más implantadas) que servían para, fundamentalmente, ayudar al programador a realizar su tarea más rápidamente. Y digo al programador porque era el único rol de Desarrollo que usaba herramientas informáticas para hacer su trabajo (aunque sólo fuera el editor de programas), dado que el resto de papeles desarrollaban su trabajo mayormente con lápiz y papel.

La propaganda que usaba aquella época Maestro (vendido en España por Philips, antes de que se fusionara con Digital, y luego ésta con Compaq, y ésta luego con HP, que ya se había fusionado con Tandem…) lo posicionaba como una Toolbox: una Caja de Herramientas diversas que el programador usaba a su conveniencia: para escribir o generar código (pero poco, ¿eh?), gestionar listados, escribir documentación, etc. Maestro funcionaba en un hardware específico (un mini Philips P7000).

El objetivo de PACBASE era más bien ayudar a seguir los pasos de la metodología seleccionada (Merise, vaya, que venía de serie con PACBASE, aunque podía usarse o no), y ayudar a escribir programas y generar código (por entonces, poco también). PACBASE era un software que funcionaba en la propia máquina para la que generaba su documentación y su código: un mainframe.

También existían algunas herramientas de Control de Proyectos (como el MS Project de ahora, vaya). Artemis era quizá la más conocida (no os extrañará si os digo que funcionaba en el mainframe, ¿no?). Sin embargo, pensada inicialmente para la Gestión de Proyectos Industriales (construcción, ingeniería, etc), tenía serios inconvenientes para su uso en proyectos informáticos, pues la asignación rígida de las precedencias entre actividades imposibilitaba controlar prácticas muy comunes en nuestro trabajo, como, por ejemplo, que un recurso (analista o programador) comience una cierta actividad sin haber terminado la precedente… esto Artemis no lo entendía, y entre eso, y el precio, no debió vender mucho en España para controlar proyectos de desarrollo, por lo que yo sé. Para otro tipo de proyectos, sí.

En cualquier caso, según mi experiencia personal, los programas de Control de Proyectos se usan exhaustivamente en la fase de Planificación del Proyecto: se emiten gráficos y diagramas Gantt preciosos, que se reparten, se discuten, se analizan, se consensúan, se enmarcan… y, una vez comenzado el proyecto, jamás se actualizan.

Si bien todas estas Herramientas fueron las precursoras de las auténticas herramientas CASE (casi, casi, los inventores), no iban a ir por ahí los tiros, por motivos obvios: el advenimiento de las nuevas técnicas gráficas de diseño, por un lado, y la generalización del uso de PC’s, por el otro, estaban cambiando rápidamente el foco. Y la aparición (mejor: el éxito) de Windows 3.0 (el primer Windows que de verdad funcionaba, sobre MS/DOS, eso sí), dotó de una plataforma gráfica usable a los desarrolladores de Herramientas Gráficas de todo tipo, y también a los desarrolladores de las propias herramientas CASE (que siguieron los pasos del CAD) para realizar programas informáticos gráficos que implementaran las técnicas de Análisis y Diseño. Sí, había también UNIX para PC en la época, y algunas de estas herramientas tenían su versión para entornos UNIX también. Ignoro si vendieron mucho o no; yo no conozco a ninguna empresa que comprara estos productos para UNIX, pero alguna habría, seguro…

Una advertencia: las compañías de software que crearon la mayoría de productos que mencionaré tuvieron una existencia movidita. Se compraron unas a otras, luego se vendieron, desaparecieron, aparecieron de nuevo… Es largo, aburrido e irrelevante detallar su historia pormenorizada: los noventa fueron años realmente interesantes para los que los vivimos…

¿Cuál de todas fue la primera de ellas? No lo sé: no me acuerdo. Pero en España, de los primeros que empezaron a vender Herramientas CASE gráficas fueron los de Coopers & Lybrand, que representaban Excelerator, de Intersolv (Intersolv ya no existe, claro, ni vende, ni su heredera recuerda a Excelerator). Era un software que funcionaba en PC, creo recordar que sólo con MS/DOS y después de 1990, con Windows 3.0 y sucesores.

Básicamente tenía adaptadas las dos técnicas de modelización: de Datos (ERD’s, de Chen) y de Procesos (DFD’s, de Yourdon), y tenía un editor que permitía crear un mínimo método alrededor.

Excelerator pintaba monos muy bonitos, era relativamente sencillo, se colgaba de tanto en cuando, y era bastante caro, pues se vendía por usuario, y su coste era de varios cientos de miles de pesetas de la época por licencia (algunos miles de euros).

También andaba por allí ADW, de Sterling Software (que tampoco existe ya, ahora es parte de Computer Associates, junto con algunos centenares de otras compañías), y Powerbuilder, de Powersoft, adquirida años después por Sybase. Te podían gustar más o menos, pero básicamente hacían cosas parecidas, y de forma parecida, a lo que hacía Excelerator, y costaban más o menos lo mismo: una fortuna.

Otra más, mucho más modesta y baratita, que apareció algún tiempo después, fue Visible Analyst Workbench, que hacía más o menos lo mismo, pero se integraba peor aún; a cambio era muy baratita comparada con las anteriores, quizá veinte o treinta mil pesetillas de nada (120 a 180 euros) por licencia. Curiosamente, Visible sigue existiendo hoy en día, quizá precisamente porque al ser sencilla y barata, fue capaz de sobrevivir mejor los avatares del fin de siglo.

Y, la última que citaré, Erwin, de Logic Works (comprada a fines de los 90 por Computer Associates, como tantas otras) excelente software especializado en el Diseño de Modelos de Datos para la tecnología relacional.

Había muchas más herramientas CASE (la verdad es que los últimos ochenta y primeros noventa vieron la aparición de decenas de herramientas de este estilo, de todo pelaje y condición: no había mes en que no asistiéramos a una presentación de al menos un par de ellas).

Sin embargo, todas las herramientas CASE basadas en PC de la época tenían un serio problema: ¿dónde almacenar los datos? En efecto, el Diseñador realizaba su Modelo, lo almacenaba en su PC, luego lo copiaba a un servidor, usando las poco evolucionadas redes de la época… pero no había forma de coordinar dos modelos diferentes de dos diseñadores distintos, ni había forma de asegurar cuál era la última versión, ni de garantizar un backup adecuado… En una palabra, su problema era la falta de integración, no sólo entre diferentes herramientas, sino incluso entre diferentes licencias de la misma.

.

Sin embargo, sí que había alguna otra herramienta que era integrada desde el principio, aunque salieron al mercado algún tiempo después de estas pioneras herramientas gráficas.

Entre ellas, a primeros de los noventa, encontramos Foundation, de Andersen Consulting. Básicamente, Foundation era un software que funcionaba mitad en PC mitad en el mainframe (no me pidáis más detalles, no los recuerdo), y que era la suma de los diferentes Métodos y procedimientos de la metodología de Andersen: Method/1, Design/1, Install/1, y alguna otra acabada en el inevitable “/1”.

También PACBASE se apuntó a la moda Cliente/Servidor (¡cómo no!), y sacó su versión integrada, donde el front-end se ejecutaba en un PC, mientras que el back-end (el almacenamiento, básicamente, y control de la información), estaba en un servidor (un mainframe, y años después cualquier cosa, incluyendo un Sistema UNIX). Los clientes que tenían PACBASE actualizaron su versión a la nueva arquitectura Cliente/Servidor, allí diseñaron sus sistemas en los noventa… y allí los siguen teniendo. Vale que es un poco ladrillo, pero es de los pocos productos que han permitido mantener la información viva a lo largo del tiempo.

Y Softlab hizo evolucionar su Maestro a Maestro II, con un diseño similar (hardware dedicado más software), pero cambiando por completo la arquitectura: el servidor pasó a ser una máquina UNIX de cualquier marca (no sólo Philips), y el front-end pasó a ejecutarse en un PC con MS/DOS y Windows 3.0. Además, proporcionó un sistema de diseño y programación interna bastante novedoso, que permitía a cada cliente implementar su propia Metodología, o adaptar con cierta facilidad las que tenían ellos ya implementadas: Merise y SSADM, por lo que recuerdo (curiosamente, Alemania, la sede de Softlab, no tenía ninguna Metodología “nacional”), y, posteriormente, Métrica, la metodología española creada por el MAP, que fue incorporada en Maestro II.

Así, era posible realizar el Análisis y Diseño Estructurado con herramientas gráficas, y almacenar su resultado en su Base de Datos interna (Orientada a Objetos y funcional… ¡ya en 1992!). Y luego realizar el Diseño Técnico y la Programación (y la generación de los objetos que se decidieran, típicamente las definiciones DB2, CICS, etc) en formato gráfico o de caracteres, según conviniera.

Recuerdo que Softlab realizó a principios de los noventa un gigantesco esfuerzo para obtener el Metamodelo de los Sistemas de Información (que era una sábana de metro y medio por un metro, lo menos), que es de lo más interesante para nuestra profesión que he visto nunca, por más que no ayudó gran cosa como argumento de su venta… pocos entendían la importancia de tal documento, que, como es costumbre, no hay manera de encontrar hoy por parte alguna…

… ¡Ah, ya!

Un… ¿metamodelo? …Y ¿eso qué es? Pues es el modelo de los modelos…

Ya, ya me explico, ya…

Los Diseñadores realizaban un Modelo (de Datos, de Procesos, etc) que representaban las Bases de Datos, transacciones y programas que iban a dar servicio a los Usuarios.

Por ejemplo, fijémonos en el ejemplo de la derecha. Es un DFD sencillo, en el que hemos modelizado un Proceso Proc1 que emite un Flujo de Datos Flujo1 (con tres datos elementales, los datos a, b y c) a una entidad externa (un Usuario), y también otro Proceso Proc2 que requiere un Flujo de Datos Flujo2 (con los datos elementales a y d) provenientes de un Almacén de Datos. Este modelo es un resultado inmediato y sencillo de aplicar la técnica de Modelado de Flujo de Datos.

Pero, si nos fijamos bien, este modelo consiste ni más ni menos que en representar la realidad (lo que los Procesos deben hacer con los Datos), de forma que sea entendible y, muy importante, almacenable (si es que este término existe). Es decir, podemos capturar los datos sobre el proceso y almacenarlos en un soporte informático de tal modo que podemos reconstruir este Modelo de Procesos a partir de ciertos datos almacenados en un fichero o Base de Datos informático. Eso es, ni más ni menos, lo que hacen todas las herramientas CASE, ¿cierto? En una palabra, el propio modelo en sí no son, a la postre, nada más que datos.

Pero los datos, del tipo que sean, son susceptibles de ser modelizados, que ya lo dijo Chen: para hacerlo, disponemos de la técnica del Modelo de Entidad-Relación. Luego los propios modelos son susceptibles de ser modelizados. Eso es lo que se llama un Metamodelo. Vamos, entonces, a modelizar la parte del modelo que conecta Procesos y Flujos de Datos (la parte sombreada en verde degradado de la figura anterior).

Claramente tenemos tres Entidades: la Entidad “Proceso”, la Entidad “Flujo de Datos”, y la Entidad “Dato Elemental”. ¿Cuáles son las Relaciones entre ellas? Un Flujo de Datos puede ser de entrada (entrega datos al Proceso) o de Salida (envía datos obtenidos por el Proceso al exterior). Por tanto, podemos modelizar dos relaciones entre Proceso y Flujo de Datos: “LLEGA” y “SALE”. Ambas son del tipo 1:n (un Flujo de Datos sólo puede llegar a o salir de un Proceso –esto podría quizá ser de otra forma, pero en nuestro ejemplo lo hemos decidido así- mientras que cada Proceso puede tener varios Flujos de Datos entrantes o salientes. Y cada Flujo de Datos puede contener muchos Datos, que a su vez pueden estar contenidos en muchos Procesos: es una Relación del tipo n:m. A continuación vemos el Metamodelo simple resultado:

Los ingenieros de Softlab hicieron esto mismo con todos los Objetos posibles con los que trabajamos los informáticos, tanto de la parte lógica, como de la física. Por ejemplo, un Programa usa una Base de Datos, una Tabla Relacional contiene Atributos (Datos elementales), una Transacción es atendida por un Programa… Todos los conceptos posibles, tanto del Análisis, como del Diseño o de la Construcción estaban allí representados. Una labor ingente, digna de mejor suerte… o simplemente de haber sobrevivido. No sé si alguien conservará alguna copia de esta información (yo no, y me encantaría), que fue un trabajo monumental… e ignorado. ¡A quién se le ocurre hacer esto en Munich, en lugar de en California!

Naturalmente, las empresas que tenían Maestro migraron a Maestro II, y Softlab hizo alguna venta más… pero pocas. Se requería un tamaño crítico grande para amortizar los costes; sin embargo, todas aquéllas que optaron por Maestro II, o casi todas, siguen hoy en día explotando la información allí contenida. Fue, a la larga, una buena inversión, largamente amortizada.

Por fin, la cuarta compañía en discordia con herramientas integradas fue Texas Instruments, que, avalada por James Martin, creó e impulsó IEF (Information Engineering Facility), una herramienta diseñada alrededor de la metodología IE, y que, ¡sorpresa!, actualmente es propiedad también de Computer Associates. Ofrecía un entorno fuertemente integrado alrededor de la Metodología patrocinada por el prestigioso Martin, donde todo funcionaba razonablemente bien, siempre que no tocaras una coma al método… y ése era precisamente su problema, porque casi nadie estaba dispuesto a adoptar la Metodología completa tal cual. También consiguió alguna venta en España, pocas realmente.

En realidad, la mayoría de empresas que decidieron entrar en el mundo de las técnicas gráficas de diseño, prefirieron hacerlo con software standalone (Excelerator, ADW, Powerbuilder, etc), que era menos útil que cualquier software integrado, pero más sencillo de implantar… y que no implicaba tomar grandes compromisos metodológicos de ningún tipo, más allá de recomendar el uso del software para hacer los diseños.

El motivo es que realmente hubo muy pocas empresas españolas que de verdad adoptaran una Metodología, sea de las existentes, sea creada ex profeso para la empresa en cuestión. Ojo, cuando digo “de verdad adoptaran”, no quiero decir que “nominalmente adoptaran”… De éstas sí que hubo muchas. Pero que realmente siguieran siempre el método, rellenando todos los documentos exigidos, haciendo (y manteniendo) todos los modelos… una o ninguna. Y quizá exagero.

Sí que se usaban los Modelos, sobre todo los de Datos: si la herramienta CASE es buena, por ejemplo, Erwin, PACBASE o Maestro II, una vez realizado el modelo se obtenía el diseño físico preliminar de las Bases de Datos, es decir, hacer el modelo ahorraba trabajo en etapas posteriores, y la gente lo usó (y lo usa). En cuanto a los Modelos de Flujo de Datos, se solían hacer los de alto nivel, sin descomponerlos mucho… y prácticamente nunca se actualizaban una vez terminados.

En cambio, realizar un Diagrama Ambidextro de Relaciones Impertinentes entre Usuarios Esquizofrénicos (un suponer), no aportaba gran cosa al Proyecto en sí, daba trabajo, no generaba nada de nada en fases posteriores, y requería mantenimiento posterior cada vez que un Usuario Esquizofrénico se convertía en un Usuario Paranoico Bipolar… Este tipo de “Diagramas Imposibles” (cada metodología al uso tenía unos cuantos de estos) creo yo que no los hizo nunca nadie. Y los inasequibles al desaliento que los hicieran, jamás los actualizaron…

En este punto, posiblemente echéis de menos a alguien… quizá os preguntaréis: ¿Y de IBM, qué? IBM era el líder absoluto en ventas, tanto de software como de hardware, siempre había tenido un fino olfato comercial, y no iba a dejar este prometedor mercado emergente sin incluir en su oferta… Y sin embargo, aún no ha aparecido en esta historia… ¿Estarían, por ventura, dormidos?

Pues no, pero sí… pero no.  O sea.

Siguiendo la experiencia exitosa de la creación y lanzamiento de sus PC’s, decidió no entrar de lleno en el mercado de la creación y venta de herramientas CASE, sino proveer un marco para la integración de todas ellas: la Arquitectura SAA (por Systems Application Architecture), que era en realidad un conjunto de normas y definiciones orientadas a permitir la interoperabilidad de todos los productos existentes, con tal que cumplieran las normas marcadas en dicha Arquitectura.

La idea era genial: como de lo que adolecen casi todas las herramientas CASE es de integración, démosle al mercado integración a mansalva… y de paso, todos los que cumplan con SAA y entren en nuestro paraguas, serán ofrecidos por nuestra fuerza comercial… ¡y nos forraremos a comisiones! Sí, la idea era genial. Sólo que, por esta vez, no funcionó. No tuvo SAA mucho éxito. Más bien poco, en realidad.

Y como producto, IBM lanzó su propio entorno integrado, AD/Cycle, obviamente en el marco de SAA, que permitía el acceso, en el lado cliente, de cualquier producto CASE y lo que proporcionaba en realidad era la solución al principal problema que tenían las herramientas basadas en PC: el almacenamiento de los modelos y los datos, es decir, la anhelada integración entre herramientas. Para ello, lanzó su muy esperado (en la época) Repositorio de Información, lugar que contendría toda la información sobre la información: los metadatos.

Algún otro repositorio había ya funcionando entonces, como el de Platinum, otra compañía más de las que, tras adquirir compañías a puñaos, acabó siendo adquirida por… ¡Computer Associates!, cómo no. Y tanto uno como otro, después de la expectación que habían levantado, resultaron un fiasco comercial. Ni vendieron mucho, ni fueron muy utilizados los que se vendieron. No sé exactamente el motivo, posiblemente el mayor de ellos, la falta de entusiasmo de los diferentes fabricantes para adoptar estándares comunes que les facilitarían almacenar su información y resolver parte de sus problemas… a cambio de permitir una absoluta compatibilidad entre herramientas.

Es decir, un cliente cualquiera tiene un puñado de licencias de Excelerator, por ejemplo, y está almacenando los modelos que crea en el Repositorio de IBM, usando el estándar SAA. Pero como ADW, un decir, también cumple el estándar SAA, mañana ese cliente de Excelerator se enfada con Intersolv, negocia con Sterling, le compra licencias de ADW a buen precio, y con ellas explota, tan ricamente, los modelos creados en Excelerator de forma transparente. Esto a los clientes nos sonaba fenomenal. Y a los fabricantes, regular. Tirando a mal… Fatal, vaya. Lo que busca cualquier fabricante es un mercado cautivo, no interoperabilidad de ningún tipo con productos competidores.

Y nunca hubo interoperabilidad real entre herramientas CASE, por mucho Ad/Cycle y mucho repositorio atómico que hubiera. Así que el resultado final fue un fracaso comercial… de todos. Ni IBM vendió mucho, ni los fabricantes vendieron mucho, a pesar de que todos, todos firmaron acuerdos con IBM para (supuestamente) integrarse con SAA… y con el tiempo virtualmente desaparecieron del paisaje. No creo que quede nadie manteniendo modelos en Excelerator ni en Powerbuilder, entre otras cosas porque debe hacer diez años o más que no hay nuevas versiones. Y del entonces famoso repositorio de IBM… no tengo ni idea de cuál es su estado actual, aunque, conociendo cómo funcionan las cosas en el mundo del mainframe IBM, supongo que habrá unos pocos por ahí instalados… pero de ahí a que se usen de verdad, va mucha diferencia.

Además, sobre los años 92 ó 93 comenzó a oírse con cierta fuerza (fuerza que se fue incrementando con el paso de los años, qué os voy a contar) la necesidad del cambio de paradigma: había que abrazar la nueva fe de la Orientación a Objetos.

Todos habíamos estado equivocados durante muchos años; había que cambiar por completo la manera de Diseñar, Desarrollar, Pensar… había poco menos que hacerlo todo nuevo. Excelentes noticias… para los Consultores, Fabricantes de Software y, sobre todo, Empresas de Servicios Profesionales de Informática. Y… ¿para nosotros, los clientes? Mmmm, creo que no mucho, y que desde luego, las supuestas ventajas del cambio de paradigma difícilmente compensa el coste del cambio… pero es mi opinión personal. Bueno, y la de muchas empresas, que siguen manteniendo sus sistemas críticos en la tecnología “de toda la vida”… pero esa es otra historia, y será contada en otro momento.

Lo que sí que quiero citar son algunas de las afirmaciones que se escuchaban entonces (y en algún caso, que se siguen citando ahora, quince o más años después… y todavía no se han hecho realidad).

1) Desarrollar aplicaciones será en realidad tomar objetos preconstruídos de aquí y de allá, y ensamblarlos sin prácticamente código nuevo. Por ejemplo, tomas el “Objeto Cliente”, el “Objeto Cuenta Corriente”, etc, que alguien habrá escrito en algún sitio de la Biosfera, y luego, simplemente, integras los Objetos entre sí, y ¡hala!, ya tienes tu aplicación de Cuenta Corrientes funcionando en un pis-pas.

2) Próximamente, a los programadores (y diseñadores, etc) se les pagará más cuantas menos líneas de código escriban, porque estarán reutilizando código preescrito. Se premiará reusar objetos, y se castigará al que escriba líneas de código.

3) Desarrollar software es como construir coches: en una planta de montaje llegan los componentes individuales y allí sólo se montan, produciendo siempre vehículos de calidad a toda pastilla.

…Y otras semejantes, que os ahorro.

Sobre la primera afirmación, que es idílica, yo siempre me pregunto… ¿y quién hace el “Objeto Cuenta Corriente”, por ejemplo? Supongamos que estamos en el Banco de Getafe, en España… ¿tomamos el Objeto Cuenta Corriente preparado por, digamos, el Banco de Bostwana? Igual en Bostwana las Cuentas Corrientes no funcionan como aquí. Bueno, tomemos, pues, el susodicho Objeto creado por el Banco de Alcorcón, que, vecino nuestro como es, seguro que cubre de perlas mi getafeña problemática. Perfecto, pero, a todo esto, ¿qué opina el Banco de Alcorcón de que su competidor, el Banco de Getafe, se aproveche de todo el conocimiento sobre Cuentas que ha plasmado en su Objeto Cuenta Corriente? Igual no le parece bien… Y si invento un tipo de Cuenta Corriente que el Objeto Cuenta Corriente que he adquirido no contempla… ¿qué hago? ¿lo modifico (y me cargo su mantenibilidad futura)? ¿compro otro nuevo? ¿lo tiro y lo reprogramo todo en Cobol?

No se trata de un problema exclusivamente técnico (que también) sino, sobre todo, comercial, de confidencialidad sobre los productos y criterios básicos del negocio, que toda empresa desea mantener ocultos a la competencia a toda costa. O sea, que podrá haber Objetos de uso general (un buen Quicksort, un objeto para validar fechas, no sé, cosas de ese estilo, por complicadas que sean). Pero ¿Objetos de Negocio, de Negocio de Verdad…? Difícil lo veo (salvo que estemos hablando de un Sistema Completo, un ERP, vaya).

De la segunda afirmación casi ni hablo: Vete tú a decir a una Empresa de Servicios que tiene que reutilizar todo lo que pueda… cuando lo más probable es que, si vuelve a construir lo que ya está mil veces construido, pueda vender una vez más las horas de desarrollo utilizadas (mejor: teóricamente utilizadas) en ello, mientras que si reutiliza, no hay horas que vender. Y las Empresas de Servicios están para facturar cuantas más horas, mejor, y ganar dinerito, no para hacer Sistemas de Información maravillosos, a costa de arruinarse.

Y, por fin, sobre lo de la fabricación de coches… me pareció siempre una falacia digna de que Pedro le dedique un post en su estupenda Serie de Falacias. Mucha gente, comerciales y vendedores, sobre todo, repetían como un mantra esta afirmación (a ver si vendían algo…). Pero es completamente falsa.

Porque el que se dedica a “fabricar coches” en la Cadena de Montaje es el Usuario Final de la Aplicación. Nosotros, los informáticos, lo que montamos es la Fábrica de Coches, la propia Cadena de Montaje. Y claro que se puede aprender de las Cadenas de Montaje que se han hecho antes, se pueden reutilizar cosas… pero si el objetivo es fabricar Mercedes Clase E, no nos vale la Cadena de Montaje de un Fiat Panda, salvo ciertos componentes aislados y no especializados ¿no os parece? Por no hablar del diseño, la aerodinámica, el equipamiento…

Creo que se ve claro, pero por si hay dudas, pongo un ejemplo tonto: Sea la Cadena de Montaje de Fiat Panda, que vamos a comparar con la Aplicación de Nómina, haciendo un exceso de imaginación, eso sí… Todos los Fiat Panda son básicamente iguales, aunque pueden llevar un par de motores diferentes, diversas tapicerías y estar pintados en dos docenas de colores distintos. Todos los empleados contenidos en la Aplicación de Nómina son básicamente iguales (sus datos, sólo sus datos, no me malinterpretéis…), unos tienen una categoría, sueldo y condiciones laborales, y otros otras, pero los datos de todos ellos están guardados en la misma Cadena de Montaje, huy, perdón, Aplicación de Nómina.

La Cadena de Montaje recibe instrucciones para la fabricación de cada coche individual: éste, Verde Botella, con motor de gasolina y tapicería yes-very-well, el siguiente rojo, Diesel y tapicería de cuero… Instrucciones concretas dentro de una lista de posibilidades reducida: sólo podemos fabricar Fiat Panda en esa Cadena, no Fiat Croma, ni menos aún Nissan Patrol… La Aplicación de Nómina procesa a los empleados según sus condiciones particulares, si tiene jornada reducida, si tiene complementos de tal y cuál, dentro de una serie reducida de posibilidades, y les calcula su recibo de nómina… pero no puede calcular la Venta por Región, ni los Ratios por Sucursal, ni realizar transferencias, porque eso lo hacen otras aplicaciones que están para eso. Ni siquiera podría calcular la Nómina de otra empresa diferente, con categorías y condiciones laborales diferentes. Fin de la analogía tonta.

Para acabar de complicar el asunto, a principios de los noventa comenzaba a existir, curiosamente una… no sé cómo llamarla, una contestación al caro Sistema Metodológico imperante. Por una parte los consultores y gurús nos decían que había que crear o adoptar una Metodología, cumplirla a rajatabla, controlar actividades y tareas (y costes, claro), documentar lo habido y por haber… Y por otra (en algunos casos los mismos consultores y gurús que nos vendían la recojo-metodología, como James Martin, que promocionaba activamente IEF, con su metodología IEM detrás, y simultáneamente era el adalid del RAD), nos decían que desarrollar todos los proyectos de esta guisa era, a su vez, muy costoso en tiempo y dinero, así que había que inventar algo para desarrollar rápidamente pequeños Sistemas de Información que no requerían tanta formalización… y nos vendieron el RAD (Rapid Application Development).

Ya unos años antes se pusieron de moda los “Lenguajes de Cuarta Generación” o 4GL, que permitían realizar programas sencillos (listados, sobre todo) sin necesidad de tanta línea de código, estructuración y todo el resto de parafernalia que sería necesaria programando en la tecnología normal (en la época, Cobol o PL/1, mayormente). El primero fue MARK/IV, luego vinieron Mapper, Nomad, Focus, Easytrieve, Mantis, Ramis, Clipper… y un larguísimo etcétera. No voy a hablar mucho de estos 4GL’s, porque me llevaría un artículo entero, y ya está bien. Sólo decir que, a pesar de que todos ellos aseguraban un espectacular aumento de la productividad (del orden de ocho o diez veces más), en la práctica no era tanto… y en ocasiones no sólo no se ganaba, sino que se perdía productividad, y siempre, siempre, se perdía rendimiento (eran mucho menos eficaces en cuanto a uso de recursos de máquina que un buen programa Cobol).

Así que, a la larga, el más exitoso de ellos ha sido Natural, de Software AG, que funciona perfectamente tanto accediendo a la Base de Datos Adabas como con el resto de Bases de Datos Relacionales, y que ha ayudado a Software AG resistir tanto cambio tecnológico habido desde entonces con solvencia.

Bueno, pues esto del RAD venía a ser una vuelta de tuerca en la misma dirección que los 4GL: mucho Usuario o Director de Proceso de Datos vio una oportunidad en aligerar costes y ganar tiempos… Se vendieron productos y metodologías RAD, en muchos casos a los mismos clientes que compraron grandes Metodologías Estructuradas unos pocos años antes… A muchos nos gustaban muchísimo estos nuevos métodos RAD (no era, ni más ni menos, que oficializar el método”a la mecagüendiez” de toda la vida, je, je).

Se compraron productos RAD de esos, se implantaron, se hicieron proyectos… En realidad, se convirtieron en un coladero, que sirvió para desarrollar proyectos que nunca jamás deberían haber sido escritos en un 4GL auspiciado por un buen RAD, ahorrando quizá algo de tiempo y dinero en su creación, pero que se convirtieron en una pesadilla para mantenerlos en cuanto estuvieron en Producción.

¿De verdad creéis que se ganó mucho? El tiempo que se ganó dejando de documentar (que tampoco se ganó tanto) se perdió luego con los mil y un problemas en la implantación. El mantenimiento era un caos, tanto que en muchos casos compensaba reescribir el código antes que bucear en el proceloso mar del código existente (¿os suena de algo, quizá, queridos lectores, esta forma de proceder con el mantenimiento?).

En cualquier caso, lo que sí es seguro es que James Martin, entre unas cosas y otras, ganó muchísimo dinero, tanto como para poder crear una Fundación con su nombre en la Universidad de Oxford y dotarla con ciento cincuenta millones de dólares de su peculio, gesto que le honra. Y nosotros, a veces atacábamos los proyectos con nuestra poderosa metodología estructurada, con sus técnicas y métodos, y a veces decidíamos que no merecía la pena meterse en tales berenjenales, y aplicábamos el paradigma RAD… o sea, ningún paradigma en absoluto. El criterio para elegir una u otra forma era, mayormente, las prisas, la presión de tiempos y costes, las querencias de cada uno… Criterios siempre muy profesionales, como podéis colegir.

.

Y… de todo esto, ¿qué? ¿Qué queda hoy en día, cuánto de este esfuerzo realizado en los años finales de los ochenta y casi todos los noventa sirve hoy para algo?

Yo diría que sí sirvió, y mucho. Nos acostumbró a seguir un método sistemático en el Desarrollo de Aplicaciones (o, al menos, a concienciarse de que los métodos existían); nos introdujo en nuevas formas de hacer las cosas, diseñando antes que programando, planificando antes de lanzarse al río de cabeza… Nos acostumbró a utilizar (y perder el miedo) a las nuevas herramientas gráficas, nos enseñó a nosotros, los creadores de Sistemas de Información, que había algo más que pantallas de caracteres 80×24 para plasmar las aplicaciones, que había otra forma de hacer las cosas. Nos fue convenciendo poco a poco, subliminalmente casi, de que otra forma de trabajar era posible. Las herramientas CASE, durante los noventa, nos fueron preparando mentalmente para aceptar la revolución que se acercaba… pero esa es otra historia, y será contada en otro momento.

Obviamente, las herramientas que se usan hoy en día son, en su mayoría, Orientadas a Objetos. Pero aún hay en Producción miles y miles de Aplicaciones desarrolladas con métodos estructurados, que hay que mantener funcionando, modificar, incorporar las nuevas necesidades… pero yo creo que rara vez se usa para esto la herramienta con que se diseñó originalmente el Sistema. Se tocan las Bases de Datos, los Programas, y punto.

O sea, que podríamos tirar tranquilamente los modelos amorosamente guardados durante años… ya no reflejan la realidad, y como decía mi primer jefe en mi primer trabajo en mi primer Banco: “para tener la documentación desactualizada, más vale no tener ninguna documentación”: te ahorras el tiempo de buscarla, mirarla, comprobar que no refleja la realidad, y te ahorras, de paso, el enfado que pillas cuando te das cuenta de que estás perdiendo el tiempo. Y total, como de todos modos no piensas actualizarla…

Herramientas CASE hay ahora mismo a cientos. Ya no conozco casi ninguna (hace bastantes años que no sigo estos apasionantes temas, y las que conocí bien… ya no existen, o sí que existen, pero como si no). ¿Se utilizan? En mi opinión, sí pero no. Se usan, al menos relativamente, para crear los modelos y las especificaciones iniciales de la aplicación. Para hacer las generaciones iniciales de Base de Datos, etc. Y, una vez puesta en Producción la Aplicación, ya se usan poco. O nada. O quizá sí que se mantenga en ciertas aplicaciones e instalaciones… Seguro, seguro, que de todo hay en la viña del Señor.

Y la vida sigue…

.

En la próxima entrada hablaré de las convulsiones tecnológicas, pero sobre todo, comerciales, de los tormentosos años noventa, donde vivimos la rebelión de los fabricantes pequeños contra el amo y señor, la antigua madrastra de los enanitos, que terminaron por convertirla a ella misma en un enanito más. Si es que os quedan fuerzas…

Disfrutad de la vida, mientras podáis.