El cambio informático y la arquitectura cliente/servidor

Cliente/servidor es la arquitectura de moda, probablemente uno de los temas más controvertidos en los ambientes informáticos de estos últimos tiempos. En estas breves líneas trataremos de aportar algunas ideas a esta discusión.

Los profesionales de la informática son objeto de constantes presiones según su mundo va registrando cambios, que sobre todo en estos últimos tiempos se están sucediendo a un ritmo frenético: cambios tanto en la manera de realizar y gestionar los negocios como en las nuevas tecnologías emergentes. Como consecuencia, la complejidad del entorno de sistemas de información va en constante aumento, y el mayor reto actual es la búsqueda de una arquitectura que se adecúe lo más posible a esta continua dinámica. Podríamos aportar muchos factores que han contribuido a la candidatura de cliente/servidor como arquitectura más adecuada a este propósito, tanto desde el punto de vista del usuario final como del departamento de sistemas de información, pero únicamente destacaremos dos de ellos:

* El auge de los sistemas personales, para los cuales se desarrollan cada día un número mayor de aplicaciones, más potentes y económicas, además de entornos de trabajo GUI de manejo atractivo y fácil de aprender.

* La posibilidad de reducir costes tanto de desarrollo como de producción, aprovechando la potencia de las aplicaciones existentes para estos sistemas personales (hojas de cálculo, etcétera)

En definitiva, la gran revolución ha sido el imparable ascenso de las estaciones de trabajo personales, y las nuevas posibilidades que esto comporta: por una parte, los usuarios finales toman conciencia de que pueden influir y manejar en mayor medida sus aplicaciones, y por otra, los departamentos de sistemas pueden integrar en sus soluciones globales esta informática distribuida, que anteriormente era prácticamente incontrolable.

Todo parece indicar que estos beneficios están comenzando a tener más peso que los interrogantes que plantea el paso a la arquitectura cliente/servidor:

* Cómo conectar entornos y tecnologías originalmente no diseñados para trabajar de forma conjunta.

* De qué manera integrar los sistemas ya existentes, de modo que se protejan las inversiones ya realizadas.

* Cómo diseñar e instalar redes de comunicación que permitan la ejecución de estas complejas aplicaciones en tiempo real.

* Cómo afrontar los costes de formación en diseño y programación para nuevos lenguajes y entornos.

El paso hacia cliente/servidor implica tener que abordar estos problemas emergentes. En este sentido, el desarrollo de sistemas conforme a esta arquitectura tan novedosa que implica integrar muchos componentes tecnológicos comporta un riesgo que no podemos dejar de comentar: El peligro de desarrollar aplicaciones cliente/servidor a la vieja usanza. ¿Qué queremos decir con esto? Aplicaciones desarrolladas con lenguajes de bajo nivel o de cuarta generación, para un servidor y clientes específicos, incluso con herramientas de prototipado muy productivas, pero que a menudo dejan el sistema escasamente documentado. Se trata, efectivamente, de aplicaciones cliente/servidor, pero, dado que integran diferentes entornos, ¿son menos o más difíciles de mantener que aquellas otras realizadas del modo tradicional a las que reemplazan?

Sabemos que el funcionamiento de las empresas y sus formas de hacer negocios está cambiando rápidamente, según se van presentando nuevas oportunidades. De la misma manera, las tecnologías no van a permanecer estáticas. ¿Queremos que nuestros nuevos sistemas cliente/servidor estén cerrados a estos cambios, o que podamos integrar fácilmente nuevas funcionalidades? El gran reto consiste en adoptar un método de desarrollo que aísle al informático de la tecnología, de manera que pueda gestionar tanto las novedades de ésta como los cambios que aparezcan en el negocio. Pero cuidado; estos cambios en la tecnología -es decir, las nuevas arquitecturas- sólo serán aceptados si implican mejoras en la productividad, respuesta a las aspiraciones de los usuarios y contención de costes. Si esto no se cumple, el departamento de sistemas no podrá justificarlos adecuadamente.

El desarrollo

En el mundo del desarrollo, los objetivos, más o menos, son siempre los mismos: mejorar la calidad y la productividad, asumir y dar respuesta a los requisitos del usuario, reducir los costes de mantenimiento y mejorar la portabilidad de las aplicaciones.

Hay unas técnicas claras para conseguir estos objetivos, conocidas desde hace tiempo:

* Definir especificaciones, no escribir código

* Usar herramientas para la generación del código

* Asegurar la re-utilización tanto de las especificaciones como del código

* Controlar la disponibilidad de especificaciones y código para todos los desarrolladores

* Utilizar metodologías formales

* Emplear RAD y métodos de prototipado

En la nueva era del cliente/servidor, estas técnicas no solamente siguen siendo útiles, sino que se convierten en absolutamente imprescindibles, tanto que podemos decir que constituyen factores críticos de éxito del cambio.Pero el grado de eficacia en su aplicación será tan elevado como permitan las herramientas utilizadas para su implantación. La situación ideal será conseguir un conjunto de herramientas que den soporte de manera global e integrada a estas técnicas.

Las aplicaciones

El usuario final tiene bien claro lo que le importa de una aplicación: que sea fácil de utilizar, que tenga buenas prestaciones y elevado grado de disponibilidad, que asegure la integridad y seguridad de los datos, que el coste de ejecución sea bajo, y, por supuesto, que cumpla sus especificaciones. No le importa demasiado, sin embargo, el método empleado en su desarrollo, siempre que su coste no lo haga prohibitivo.

Con la revolución de la informática de sobremesa, los usuarios comienzan a reclamar características adicionales para sus aplicaciones: que tengan el mismo aspecto que sus herramientas de PC y que sean integrables con ellas. En un entorno multiusuario, esto significa cliente/servidor.

En el desarrollo tradicional, se han utilizado una serie de tecnologías (monitor de teleproceso, SGBDR, PC/LAN, etc.) que no van a dejarse de lado en esta nueva era. Lo que va a cambiar en cliente/servidor es la manera de manejar estos componentes: una aplicación podrá acceder a un SGBDR a través de un monitor de teleproceso en entorno mainframe, desde un cliente (PC) con entorno GUI nodo de una PC/LAN. Las tecnologías no son enteramente nuevas, pero sí se utilizan de forma integrada.

¿Va a significar esta nueva forma de trabajo una gran inversión en formación y re-adiestramiento de los desarrolladores? La respuesta dependerá de las herramientas y técnicas que se seleccionen. Si cada vez que cambie la arquitectura se deben aprender nuevos lenguajes y entornos, evidentemente el coste será elevado; no es aprovechable la formación en lenguajes, protocolos de red o sistemas operativos que pueden cambiar. Pero si se utilizan herramientas que permiten aislar de alguna manera el cambio tecnológico, el esfuerzo necesario será mucho menor, ya que la formación se impartirá de una vez y para siempre.

Reutilización de Especificaciones

Para muchas organizaciones, el cambio a cliente/servidor implica un reto añadido: ¿cómo integrar las aplicaciones existentes que van a seguir funcionando, de manera que puedan evolucionar en el nuevo entorno y no se pierda la inversión ya realizada?. En este sentido, es importante darse cuenta de que, independientemente de la tecnología, las reglas de negocio de un sistema son siempre las mismas, ya esté implantado como on-line, batch, como cliente/servidor o en un simple PC.

Sería muy conveniente en este sentido poder separar la tecnología de las reglas