El mito de las aplicaciones multiplataforma

Poner en marcha y mantener aplicaciones para múltiples plataformas no es un proceso rápido ni sencillo. A pesar de las promesas de los vendedores de software, pueden requerirse para ello meses -y a veces años- de preparación, tests piloto e implementación. Y, en muchos casos, un plan para establecer aplicaciones en múltiples plataformas concluye con una disminución de las expectativas y unos compromisos a medida de la situación.

Es razonable esperar que unas aplicaciones que funcionen en múltiples plataformas sean en cierta medida inconsistentes: los vendedores y los desarrolladores de aplicaciones intentan aumentar al máximo el uso que hacen de las características especiales de la plataforma mientras mantienen las funciones y características básicas. Sin embargo, los problemas de ejecutar una determinada aplicación en múltiples plataformas de hardware y sistema operativo van más allá de simples variaciones en el estilo de menú. El énfasis de los vendedores en una plataforma dominante del mercado como Windows puede significar que productos para otras plataformas, como Unix u OS/2, queden muy por detrás en sus fechas de presentación en el sector. Uno de los motivos clave para adoptar una determinada marca en la totalidad de una empresa es la compatibilidad de ficheros, y es un factor que continúa impidiendo la adopción de numerosas marcas.

Dejando de lado la reputación de la plataforma y sus defensores, generalmente demasiado entusiastas, el departamento de Sistemas de Información deberá analizar las necesidades de la empresa, el hardware existente y la capacidad y conocimientos del departamento, necesarios para comprometerse con un determinado producto y con la plataforma que soporta.

¿Opción o imposición?

Actualmente, el soporte para múltiples plataformas no es una opción elegible, sino una realidad vital y obligatoria. Un departamento informático puede soñar con establecer como estándar una determinada plataforma y, sin embargo, en la realidad, diferentes departamentos y grupos de usuarios tendrán sistemas no estándar. El departamento de marketing podrá utilizar ordenadores Macintosh porque necesita buenas capacidades de autoedición desktop para producir un boletín mensual, mientras que el grupo de ingeniería podría utilizar estaciones de trabajo Unix, y unos cuantos usuarios podrían tener instalado el sistema OS/2. Los usuarios desean y necesitan funciones idénticas en todas las plataformas, con unas necesidades de formación de personal nulas o escasas y un soporte técnico fiable, mientras que los directores de Sistemas de Información buscan facilidad en el despliegue, soporte técnico y administración. Todo esto parece razonable, dada la gran cantidad de proveedores de software que anuncian sus productos para múltiples plataformas. Pero las promesas y la realidad suelen ser diferentes.

Suele ocurrir que las diferentes plataformas no estén al mismo nivel en cuanto a funciones y características. También es importante el soporte de tipos de letra. En algunos casos, los tipos de letra no se producen de forma consistente en todas las plataformas, e incluso en una misma plataforma un tipo de letra puede aparecer de forma diferente dependiendo del tipo de monitor del usuario.

Estos problemas son especialmente frecuentes cuando se trata de software que funciona en plataformas Macintosh y Windows. De hecho, múltiples programas Macintosh fracasan al equipararse con sus equivalentes Windows en cuanto a características, funciones o fiabilidad. Cuando Microsoft presentó Word 6.0 para el Macintosh, después del lanzamiento con éxito de Word 6.0 para Windows, los usuarios Macintosh se mostraron bastante críticos. Esta versión era la primera demostración de la estrategia básica de codificación común de Microsoft, en la que entre un 70 y un 80 por ciento de la codificación de aplicación se considera independiente de plataforma. La estrategia estaba diseñada para permitir a Microsoft presentar un programa para múltiples plataformas dentro de un corto periodo de tiempo.

Era un buen objetivo, aunque, por el motivo que fuera, Word 6.0 para el Macintosh incluía muchos errores, y muchos usuarios Macintosh se preguntaron si la codificación básica habría sido optimizada para Windows.

La opinión de los vendedores

Al preguntárseles sobre el decepcionante soporte multiplataforma, los vendedores replican que sufren cierto número de presiones que afectan a la cantidad de plataformas que pueden soportar y a la medida en que pueden hacerlo. Entre los principales problemas está el de saber si existe un mercado que soporte los costes de desarrollo, aunque las consideraciones técnicas desempeñan también un papel a tener en cuenta.

Ofrecer productos que funcionen en múltiples plataformas resulta complejo. Hay que enfrentarse a múltiples diferencias en sistemas operativos, y en el caso de productos de redes o comunicaciones a entre 70 y 80 conjuntos de protocolos de red diferentes.

Los interfaces GUI API varían para cada plataforma, a veces considerablemente. La mayoría de las aplicaciones tienen más cosas en común respecto a la Entrada/Salida de ficheros y la gestión de memoria que el interface GUI, por lo que estas áreas de desarrollo no son tan intensivas. Y, al nivel más bajo, la mayoría de los sistemas operativos se parecen a Unix en cierto grado.

La mayoría de los desarrolladores crean un subset del interface GUI, en lugar de un superset, lo que hace que el interface sea más débil. Y es cierto que en algunas plataformas no existen unas verdaderas funciones y características, así que los vendedores las simulan.

Los directores de Sistemas de Información que soportan una estrategia de multiplataforma deben tomar en consideración varios factores al seleccionar software para múltiples sistemas. Lo primero es determinar si el programa en cuestión soporta funciones y características clave en todas las plataformas.

Los usuarios y el personal informático utilizan con frecuencia el interface de usuario como indicador de en qué medida el cliente es aceptable como una aplicación multiplataforma. Generalmente los usuarios se dividen en dos campos al juzgar a un cliente por su interface GUI: mientras que unos dicen que el cliente debe adaptarse a estándares GUI específicos de cada plataforma, otros afirman que el interface GUI debe ser idéntico en toda la solución software. Si el interface GUI de una aplicación no funciona lo mismo ni tiene la misma forma en todas las plataformas, se convierte en un problema de soporte técnico. Todo el mundo en todas las plataformas debe ser capaz de utilizarlo de la misma manera, o de lo contrario la formación de personal y el soporte técnico -en cualquier sistema- podría convertirse en una pesadilla.

Cualesquiera que sean las preferencias y las preocupaciones de los clientes, los directores de informática buscan una plataforma de servidor que sea fiable, ofrezca buenas herramientas de administración y seguridad, sea escalable, y pueda soportar un gran número de usuarios simultáneos sin quedar fuera de acción.

¿Cuándo cambiar?

En algunos casos, una empresa tiene que cambiar las aplicaciones con el fin de obtener una determinada capacidad o para obtener soporte de una determinada plataforma. Al aparecer nuevos productos, los usuarios finales y los directores comerciales podrían verse tentados a adquirirlos, pero los directores de Sistemas de Información consideran que una vez que se establece un determinado estándar, las empresas no deberán alterar su matriz de configuración para incluir la solución de plataforma más reciente y mejor. Si la instalación y el soporte de aplicaciones comerciales en un entorno multiplataforma es difícil, crear aplicaciones propias para múltiples plataformas puede ser casi un milagro y requiere un rigor especial. Sin embargo, en algunas empresas sí está ten