El proceso cliente/servidor vale la pena, pero....

La mejor manera de comprobar la idoneidad de una solución cliente/servidor es observar la experiencia de algunas compañías. En este artículo se narra la experiencia real de cinco grandes empresas de diferentes sectores de actividad.

Compañía aérea

Menores costes, mayor eficiencia en el proceso, y una mejor planificación de la actividad de los empleados, eran los objetivos de esta compañía aérea al cambiar su aplicación de programación de la actividad de sus equipos de vuelo desde un mainframe 3090/600 a un entorno cliente/servidor, a comienzos de los años 90. Dieciocho meses después -con un retraso de seis meses frente a lo proyectado- la compañía alcanzó sus objetivos.

El proyecto entró en funcionamiento después de lo previsto porque esta compañía no había previsto el tiempo que sería necesario para investigar la multitud de ofertas cliente/servidor disponibles y formar a los programadores mainframe en el nuevo sistema basado en Unix. El equipo de sistemas de información empleó meses hablando con docenas de vendedores, diferenciando los "vendedores de hardware y software puros" de aquellos que estaban dispuestos a actuar como consultores y responder a las cuestiones de la compañía sobre arquitecturas de proceso distribuido.

En ocasiones, la decisión no se adoptó en base al mejor hardware o su coste, sino en base a si el vendedor era capaz de responder a las cuestiones. La compañía buscaba experiencia y conocimientos, porque, desde un punto de vista técnico, estaba entrando en un terreno desconocido.

Al final, adquirió procesadores de Silicon Graphics y estaciones de trabajo IBM RISC System/6000 basadas en Unix, funcionando con software de SAS Institute para entrada de datos, edición y gestión de ficheros.

Mover el sistema de planificación a una arquitectura de proceso distribuido permitió evitar un upgrade de mainframe que hubiera costado en torno a cuatro millones de dólares. Además, la nueva arquitectura ha más que duplicado el tiempo de CPU disponible para planificar los tests de los analistas y establecer planes mensuales para los 8.000 pilotos y 17.000 auxiliares de vuelo de la compañía.

Cuanto más tiempo de CPU se obtenga para la aplicación de planificación, mejores serán los resultados, y cuanto mejores sean los resultados, menores serán los costes de planificación. Globalmente, la compañía espera ahorrar en torno a un millón y medio de dólares anuales como consecuencia de la mejora en la planificación.

Aunque el proceso cliente/servidor está funcionando bien, los responsables de su implantación aconsejan no subestimar la cantidad de reentrenamiento del personal que requiere un paso al proceso cliente/servidor. Uno de los principales culpables son los materiales de formación inadecuados. No hay ningún manual que diga, "si esta es la forma en que se hacía una cosa en el mundo mainframe, esta es la forma en que hay que hacerlo ahora en el proceso cliente/servidor". Los programadores de mainframes deben aprender y adquirir experiencia en la gestión de la planificación de capacidad y en las técnicas de seguridad. También deben de aprender a trabajar en un entorno de red.

Un compromiso con el proceso cliente/servidor significa un compromiso con la formación del personal. El escenario típico, consistente en codificar y después realizar una demostración no funciona en este entorno. Los usuarios necesitan la oportunidad de aprender y ejercitarse en todo esto. A pesar de los desafíos del proceso cliente/servidor, la compañía no volvería atrás: "se asumen riesgos a cambio del enorme potencial de reducción de costes y mejora del proceso".

Empresa del sector industrial

Hace tan solo un año, los clientes que llamaban a esta compañía para hacer un pedido o solicitar reparaciones sólo tenían una pequeña oportunidad de recibir ayuda sin ser transferidos una o más veces a un departamento o a un representante de servicio diferente. Este no era un buen historial para una compañía que quería aumentar sus ventas, así que se decidió que, para mejorar el servicio, necesitaba establecer un único punto de contacto con los clientes. Con este fin, la empresa decidió desechar su sistema de entrada de pedidos basado en mainframe, difícil de utilizar y con 20 años de antigüedad, y pasar a una arquitectura de proceso cliente/servidor. El proyecto permite a los representantes de servicio un acceso universal a los datos de pedidos, servicio y reparaciones. De esta forma, los clientes pueden solicitar ayuda llamando a un único número.

El paso primero y más crítico en esta migración, cuyo coste ha ascendido a 15 millones de dólares, ha sido crear una infraestructura capaz de soportar aplicaciones cliente/servidor basado en Unix. Esto ha requerido, entre otras cosas, crear una red TCP/IP (Transmission Control Protocol/Internet Protocol) aparte, e implementar estructuras de gestión y control de red; establecer estándares cliente/servidor globales; desarrollar experiencia en el sistema operativo Unix; y formar a los desarrolladores de aplicaciones en los lenguajes C y C++.

Desde el comienzo, el énfasis se centró en dedicar tiempo y energía a la infraestructura más que a las aplicaciones, las cuales, en comparación, resultan fáciles.

14 meses después de ponerse en marcha el proyecto, la compañía completó los tests de infraestructura y comenzó a sustituir los equipos desktop de sus 3.000 representantes de servicio, sustituyendo terminales 3270 por estaciones de trabajo Hewlett-Packard equipadas con el sistema X Windows. Los clientes están enlazados a través de la red TCP/IP a servidores HP, que contienen toda la lógica de aplicaciones, y al mainframe, que actúa tanto de base de datos como de gestor de datos.

El sistema cliente/servidor entró en estado completamente operacional dos meses más tarde que los 21 meses previstos en el plan. El problema estuvo en subestimar el tiempo y el esfuerzo necesarios para integrar diversos componentes cliente/servidor del sistema, incluyendo múltiples bases de datos y aplicaciones y un sistema de interface gráfico de usuario.

Compañía petroquímica

Esta compañía del sector petrolífero se enfrentaba al desafío de ofrecer a los usuarios un acceso sin fisuras a múltiples bases de datos basadas en sistemas VAX y mainframe, conteniendo datos sobre exploraciones y producción de petróleo. Además, la compañía deseaba crear un entorno de proceso del tipo plug-and-play que permitiese a aplicaciones tanto nuevas como ya existentes acceder a datos en toda la compañía.

La compañía resolvió parte del problema creando lo que denominan un "servidor de datos virtual" que combina una base de datos relacional Sybase, funcionando en un servidor Sun de base Unix, con una serie de gateways desarrollados internamente.

El sistema sustituye a un sistema de base de datos propietario enlazado a un sistema VAX de Digital, que ha sido desechado.

La creación del proyecto requirió 18 meses y costó aproximadamente un millón y medio de dólares (un millón en personal y el resto en hardware y software).

Bajo el nuevo sistema cliente/servidor, los usuarios acceden a datos de exploración y producción de petróleo desde PCs y estaciones de trabajo basadas en procesadores de Intel y estaciones de trabajo Unix que utilizan software cliente de Sybase.

Las aplicaciones iniciales, cuya conversión requirió el doble de tiempo de lo previsto en un principio, están dirigidas a tareas específicas, como la generación de mapas geofísicos y el análisis de pozos petrolíferos.

Aunque el uso de software de bases de datos preparado facilitó el proceso global de implementación y desarrollo, la migración a un sistema cliente/servidor no estuvo totalmente libre de problemas. Lo mismo que otras firmas antes, se subestimó el tiempo y el costo necesarios para la formación de los programadores de