La verdad sobre los costes del proceso cliente/servidor

¿Puede ahorrarse dinero en una migración desde un entorno mainframe a otro cliente/servidor? Parece que la respuesta es afirmativa, pero sólo si se tienen en cuenta a priori todos los posibles costes ocultos.

Cuando la mayoría de las personas consideran los ahorros de costes que pueden obtenerse con el proceso cliente/servidor, piensan en las historias extraordinarias sobre compañías que desechan sus mainframes, sustituyéndolos por redes de área local, ahorrando así millones. Es cierto que mover aplicaciones fuera de los mainframes a sistemas más pequeños puede permitir ahorrar hasta un 50% en costes de hardware, pero lo que es cierto también es que los ahorros de hardware son contrarrestados en ocasiones por ciertos costes que suelen pasarse por alto, principalmente los resultantes de establecer y a continuación mantener en funcionamiento un entorno cliente/servidor.

Los directores de sistemas de información con visión suficiente establecen planes para esos costes, aprovechan medidas sencillas de reducción de costes e implementan tecnología cliente/servidor en áreas que ofrezcan el máximo beneficio sobre la inversión. De esta forma, tienen la seguridad de obtener unos ahorros de costes realistas.

Costes inesperados

La lista de compañías que están pasando al proceso cliente/servidor va en aumento. Sin embargo, aunque muchas empresas y organizaciones proponen esta tecnología, reconocen que los ahorros que esperaban no se han producido. Esto se debe a que los costes inesperados tienden a hacer desaparecer los ahorros. Es necesario por lo tanto precaverse ante los factores de supresión de ahorros siguientes:

 Costes de formación. Una vez que se implementa por completo el proceso cliente/servidor, los conocimientos necesarios en un departamento de sistemas medio cambiará. El personal existente deberá ser reentrenado o sustituido.

En el pasado, el personal informático sólo era responsable de un sistema central: sus aplicaciones, backup de ficheros, problemas de rendimiento y puesta a punto de sistemas. El personal en un entorno cliente/servidor debe atender también a esas tareas, pero en sistemas dispersos. Por ejemplo, dependiendo de dónde se produzca un atasco, necesitarán tratar con el sistema, la red o algún hub extraño y alejado.

Cuando la formación tiene lugar en el propio trabajo o en una clase, hay que estar preparado para invertir algún dinero para que el personal adquiera la velocidad necesaria en las actividades de PCs, redes LAN, aplicaciones PC, gestión de redes y sistemas, desarrollo de aplicaciones, prototipos y soporte para aplicaciones de usuario final.

El antiguo personal de grandes sistemas tendrá que aprender a manejar lo relativo a gestión de activos de software, gestión de configuraciones, análisis de rendimiento, archivos, backup y otras actividades de gestión en configuraciones basadas en red. El personal de programación de mantenimiento tendrá que cambiar de velocidad, ya que los usuarios finales se mantendrán modificando sus propios programas y generando sus propios informes, bases de datos e incluso aplicaciones.

El porcentaje de tiempo, entre un 75% y un 90%, empleado por los programadores disminuirá, dejándolos libres para nuevos desarrollos cliente/servidor, incluyendo el establecimiento de ficheros provisionales para usuarios finales. También pueden ocuparse en establecer vistas de bases de datos para ayudar a los usuarios a realizar su propio mantenimiento. Sin embargo, no es suficiente con entregar a los programadores nuevas herramientas basadas en PCs. Lo que se requiere es un cambio en la filosofía de desarrollo a los niveles más altos en la organización de sistemas. El modelo de ciclo de desarrollo de aplicaciones, en el que el diseño se planifica para hacer frente a todas las eventualidades posibles, debe dar paso a un diseño de sistemas que sea flexible y reutilizable. Los sistemas pueden hacer su debut en un plazo de meses.

Todo el mundo en el sector informático debe hacerse partícipe de esta forma de pensar. Sólo entonces tendrá sentido para el personal adquirir y aplicar conocimientos y capacidades en lenguajes C++ y de cuarta generación, y métodos de acceso a bases de datos relacionales.

 Costes de personal asociados a la gestión de sistemas y redes. Aunque los costes de tecnología podrían descender en entornos cliente/servidor (los millones de instrucciones por segundo en PCs son menos costosos y el hardware puede amortizarse con el tiempo), estos ahorros tienden a quedar contrarrestados por el alto costo del personal adicional.

Un área en la que esto es particularmente notorio es en la gestión de sistemas y de redes. Los vendedores empiezan ahora a ofrecer herramientas para una gestión centralizada y de alcance total de sistemas heterogéneos distribuidos. Hasta que esto esté totalmente consolidado, se necesitarán personas para atender a la coordinación del software, corrección de fallos, llamadas help desk y gestión de configuraciones en las instalaciones remotas.

Algunos departamentos informáticos piensan que una forma de reducir los costes de personal está en una gestión del backbone mientras se delega la gestión de redes LAN y sistemas remotos a los usuarios finales. Esta podría no ser una buena estrategia a largo plazo. Cuando sea finalmente posible una gestión centralizada, podría resultar difícil recuperar el control y consolidar las instalaciones. Los costes de personal podrían aumentar al quedar la gestión bajo su dominio.

 Costes de telecomunicación. Permitir a los usuarios acceder a información en cualquier parte de la red, no importa donde esté el usuario, es el potente atractivo que ofrece el proceso cliente/servidor. Sin embargo, al hacerse más corriente el acceso a los sistemas en la red, y al resultar más portátiles los métodos de acceso, los costes de utilización de la red resultan más difíciles de predecir. Los usuarios actuarán de igual a igual en la red, dondequiera que se encuentren.

 Costes de planificación de capacidad. La mayor parte de los sistemas mainframe o de miniordenador actuales disponen de herramientas y normas para calcular la compra del sistema, supervisar la utilización de éste, distribuir las cargas de trabajo y ayudar a planificar compras futuras.

Desafortunadamente, en el mundo C/S no existen estas herramientas y capacidades. Por ejemplo, el departamento informático no puede realizar con efectividad la supervisión de sistemas en redes de PCs. Las cargas de trabajo se establecen normalmente para rendimiento global o "throughput" de transacciones, no para el uso interactivo y compartido de ficheros ni para consultas de datos ad hoc.

Como consecuencia de ello, la planificación de la capacidad resulta imprecisa: uno nunca está seguro de si se ha comprado demasiado o demasiado poco. Adquirir demasiada capacidad es una proposición costosa, aún más si se tiene en cuenta que puede impedir el paso a la siguiente ola tecnológica. Resulta difícil justificar el paso a algo nuevo cuando ya se dispone de más que suficiente en sistemas. Una capacidad demasiado baja afecta en gran medida al presupuesto, ya que a largo plazo será necesaria una costosa renovación.

El mejor consejo es: al considerar una compra, hacer que el vendedor ejecute las aplicaciones, para ver si el sistema puede manejar lo que uno ya tiene.

 Costes de escalabilidad. Los vendedores están desarrollando muchas herramientas cliente/servidor para los entornos PC y PC LAN. Sin embargo, como estas aplicaciones y redes han sido diseñadas para manejar las necesidades de comunicaciones de pequeños grupos de trabajo, no siempre son escalables a un entorno mayor y con mayores exigencias. La opción en muchos casos es un cambio costoso, bien añadiendo múltiples servidores o comenzando de nuevo con un miniordenador.

Medidas para la reduc