Hosting de aplicaciones disfrazadas de Software-as-a-Service. No es lo mismo

24 Nov 2010 en Software

Algunas tendencias en el mundo del software son más el bombo de los proveedores que fruto de la demanda. Pero en Software-as-a-Service (SaaS) y su ambiente mayor, Cloud Computing, existe demanda. No se trata de una demanda frontal y total, pero sí son muchas las organizaciones que optan por el modelo “on-demand” que encierra SaaS.
Esta alternativa de software como servicio en lugar de la tradicional instalación en casa del cliente, lleva a que muchos proveedores cambien la presentación de sus productos existentes y los presenten como soluciones SaaS o Cloud Computing. Pero eso no quiere decir que alcancen el verdadero potencial de esta opción.
Este ejercicio de los proveedores ha sido bautizado como “cloud washing.” Esos proveedores quieren mostrar que se actualizan al ritmo de la innovación y del mercado, pero no es cierto.
Muchos de estos ISVs (Independent Software Vendors) están portando sus paquetes de aplicaciones a entornos como el de Amazon Web Services (AWS) u otros servicios de hosting, proclamando tener SaaS.
Esta clase de pseudo-SaaS tiene la ventaja de alejar del cliente las complicaciones de la implantación y administración del software, sus recursos físicos, etc. Sirve también para eliminar algunos costos característicos de un entorno on-premise, pero no entrega los mejores beneficios de una solución SaaS.
Una diferencia notable es que las soluciones “hosteadas” siguen exigiendo que el cliente adquiera una licencia perpetua, excluyendo los beneficios de una suscripción “pague-por-lo-que-usa,” característica de SaaS. Aunque se ofrezca un leasing, no es algo financieramente tan flexible como el modelo de precios SaaS.
Un ISV tradicional, aunque entregue vía hosting, actualizará su software con poca frecuencia
ya que los clientes usan una misma instancia de su aplicación y la implementación de mejoras es lenta y costosa para el ISV. En cambio, los verdaderos proveedores SaaS, actualizan y mejoran sus soluciones regularmente en base al feedback de sus clientes y a las innovaciones de la industria.
A un ISV, le resultará muy complicado crear una comunidad donde sus usuarios compartan herramientas o mejores prácticas,
ya que tienen instancias separadas del software y no un recurso compartido.
Los ISVs no pueden capturar datos de utilización en común de sus usuarios. Esos datos, en el caso de una solución SaaS, permiten identificar y priorizar mejoras a los productos, además de conformar valiosa información de benchmark para que sus clientes optimicen sus operaciones.
La verdad es que muchos ISVs que explotan alternativas como la de Amazon (AWS) u otras, todavía no apuestan a una estrategia SaaS completa. Están probando la receptividad de los clientes y su propia capacidad de responder a la demanda, antes de realizar las inversiones necesarias y migrar sus aplicaciones a una arquitectura SaaS. Esto último exigiría reestructurar sus propias operaciones para poder vender, entregar y soportar con éxito esta clase de solución.
La asociación con AWS u otros, tiene sentido para los ISV. Sin embargo, no lo tiene tanto para sus potenciales clientes, que se verían dependiendo de proveedores ambivalentes a los que les cuesta convertirse en proveedores de servicios y dejar de ser proveedores de productos.
Para la gente de IT, la recomendación que hace Jeff Kaplan, columnista de Datamation y director de THINKstrategies, es la de analizar detalladamente si un ISV que emplea esas estrategias de llegada al mercado, tiene un compromiso real y de largo plazo con SaaS. Debe verificar que el proveedor esté dispuesto a realizar las inversiones necesarias para entregar todos los beneficios de SaaS. De otra manera, quedará en riesgo de apoyar sus operaciones en un proveedor que puede cambiar de curso en la mitad del camino.