¿Qué es el software como un servicio?

Introducción

Ha habido confusión acerca del significado de software como un servicio (SaaS) y en demanda. Esta confusión, arraigada aún más por la existencia de los modelos anteriores de hospedaje y del proveedor de servicios de aplicaciones (ASP), ha engendrado un rango de suposiciones algunas veces incorrectas o borrosas. Para varios es difícil comprobar si SaaS o en demanda implican que

1. la aplicación del software está hospedada; que es un tipo de intermediario hospedado que es necesario para proporcionarles a los usuarios el acceso al software, a un nivel de servicio garantizado.
   
   
2. el software está disponible solamente en una forma hospedada, fuera de sitio y está accesible por medio de un navegador Web, a través de un modelo de tipo autoservicio, no a través de discos compactos (CD) o cargas; o
   
   
3. el software está disponible por medio de un modelo de suscripción, donde los usuarios pagan en una base diaria, semanal, mensual o por usuario.

Esta es la segunda de cuatro partes que conforman esta serie, El software como un servicio está ganando terreno.

Ciertamente, la reciente generación del software, diseñada desde cero para entregarse como un servicio, fundamentalmente difiere de los modelos de hospedaje tradicionales. Esta nueva generación ofrece un número de beneficios que aquellos primeros modelos de entrega no podían ofrecer. En concreto, aunque los modelos de hospedaje SaaS todavía están evolucionando, varios de los problemas tecnológicos que estropearon la primera ola de ASPs han sido o se están resolviendo. Por ejemplo, además de las mejoras en la seguridad y la reducción de precios para el ancho de banda que es un buen presagio para la adopción de hospedaje, finalmente el software hospedado se parece más a las aplicaciones tradicionales cliente/servidor de interfase rica de usuario. Esto es debido a que las herramientas como JavaScript que proporcionan revisión de errores y validación por parte del cliente. Además, y posiblemente más importante, el desarrollo del lenguaje de marcas de hipertexto dinámico (DHTML), ha permitido que el contenido Web cambie cada vez que se ve, al permitir que una página Web reaccione a los ingresos del usuario sin la necesidad de enviar solicitudes al servidor Web. Esto, en particular, ha introducido un grado de interactividad a las aplicaciones basadas en la Web que simplemente no era posible hace algunos años. En ese entonces, los usuarios se enfocaban a llenar y presentar engorrosas formas de lenguaje de marcas de hipertexto (HTML), o tenían que correr un software adicional de cliente esbelto, como Citrix MetaFrame, en sus escritorios. Ninguno de estos acercamientos será satisfactorio, a pesar del hecho de que mientras el software de cliente esbelto de igual forma prometía una buena solución, todavía tenía un gran número de defectos.

Primero, el software de cliente esbelto aumentaba los costos debido a que el software tenía que tener una licencia por usuario, una idea que el modelo de hospedaje liquidaría. Esto con frecuencia causa que el costo de la licencia de Citrix MetaFrame sea de más de la mitad de una cuota mensual menos que atractiva. Segundo, porque la pantalla se “prestó” de forma efectiva a kilómetros de distancia de donde se localizaba el usuario, y era lento y aumentaba la carga en la red cuando el ancho de banda era extremadamente caro era. Por último, los usuarios todavía tienen que operar y mantener la propiedad del software del cliente esbelto en sus escritorios, derrotando el objeto del software basado en la Web y centrado en el servidor. Como resultado, los costos no se reducen tanto como se prometió en un principio.

Sin embargo, con la llegada de nuevas herramientas, esto ha mejorado mucho. En términos del navegador, todavía hace falta el soporte para gráficas muy avanzadas, mientras que la necesidad de interacciones complejas por el lado del cliente se ha mitigado con la ayuda de DHTML con la reducción del los viajes redondos y la regeneración de página del servidor. Se deben esperar más desarrollos que permitan escenarios de interacción más sofisticados en el futuro próximo. Básicamente, las aplicaciones SaaS bien diseñadas deben ser capaces de fortalecer las metáforas de la interfase de usuario rica, sin aprobarlas.

Con base en esto, uno puede definir SaaS como componentes de software que se desarrollan o se compran y están hospedados por un proveedor de servicio independiente, y que se facturan sobre una base de uso de recursos o por usuario (que se puede cambiar y no es una cuota mensual fija). Estos componentes de software no requieren ninguna infraestructura manejada o perteneciente al usuario, excepto para el acceso a Internet. El software se soporta en una plataforma de infraestructura virtual hecha de equipo físico, como redes y servidores; se almacena dentro de los centros de datos comerciales y de las aplicaciones lógicas, como sitios Web; aplicaciones; y software de base de datos, que opera en el hardware físico y lo entrega un tercero independiente.

Diferente al hospedaje de aplicación tradicional

Es importante distinguir SaaS del hospedaje de la aplicación tradicional. Por lo general, un alquiler de hospedaje tradicional significa que el usuario todavía compra el software y el hardware pero lo financia en pagos mensuales. Bajo estos términos, la empresa usuaria de hospedaje tiene los derechos del software de hospedaje, pero la suscripción es esencialmente un pago a un tercero para manejar el hardware y los aspectos de infraestructura de la instalación. En el modelo ASP, el vendedor ASP por lo general es dueño del software. La suscripción compra el derecho de ingresar al software por el periodo de suscripción en una base de tiempo o de uso (por ejemplo, tanto por tal transacción).

Por el contrario, en el modelo SaaS, no existe una inversión inicial de capital, y ningún software o hardware que comprar. Los usuarios y sus socios de implementación (desarrolladores Web e integradores de sistemas) pueden solo personalizar y manejar el contenido, diseño y lógica comercial de sus páginas o sitios Web. Un buen ejemplo de esto es la forma en que los bancos utilizan servicios para procesar cheques. Mientras que el software se utiliza para operar tales servicios, los bancos no pagan el ingreso al software, pero en lugar pagan por un servicio de libramiento de cheque. Otro ejemplo sería la forma en que las aerolíneas utilizan los sistemas de distribución mundial como Sabre.

También existen diferencias técnicas entre SaaS y el hospedaje de aplicación. En el modelo tradicional de hospedaje, referido como de un solo arrendamiento, un proveedor de servicio le da licencia a una aplicación de un vendedor de software independiente (ISV) y remotamente hospeda y maneja la aplicación (posiblemente por medio de un ASP), por lo general por un cargo inicial y una cuota de mantenimiento mensual. En este modelo uno a uno, a pesar de la alta disponibilidad y de un bajo riesgo de violación a la seguridad y de la interrupción de servicio, los usuarios se encontrarían atorados en situaciones donde no podrían desplegar nuevas características rápidamente o responder ágilmente a la demanda cambiante del cliente.

Para explicar esto de forma más clara, se debe visualizar un corredor con varios casilleros a la izquierda y a la derecha. Estos casilleros contendrían servidores de bases de datos, servidores de aplicación, servidores de sistema operativo (OS), y demás, y cada casillero hospeda su propio usuario, un sólo inquilino. Cada casillero correría en un caso o versión de la aplicación. Dependiendo de la capacidad máxima, algunos casilleros serían más grandes y contendrían servidores latentes si el inquilino predijera que los necesitaría durante periodos máximos. En este sólo inquilino, de arreglo de casos múltiples, cada inquilino gasta mucho tiempo, esfuerzo y dinero para personalizar su aplicación para poder hacer su sitio único. La personalización requiere desarrollar el código que falta en la aplicación de la base original o modificar la funcionalidad limitada y existente para replicar las características de las mejores prácticas. Por lo tanto, al igual que con las aplicaciones tradicionales en premisa, estas aplicaciones hospedadas también requieren que los desarrolladores trabajen en la funcionalidad que no está disponible en la aplicación original. Esto lleva mucho tiempo y dinero y no se soporta la personalización. Cuando el ISV tiene un nuevo lanzamiento de la aplicación, es casi imposible desplegarlo en las distintas versiones personalizadas, ya que puede romper la enorme inversión en la personalización.

En contraste, el modelo SaaS hace uso de la arquitectura del software de arrendamiento múltiple, en el que un caso del software y del modelo de datos se les proporciona a múltiples clientes que comparten el mismo hardware y base de datos. Con la arquitectura de arrendamiento múltiple, el software puede monitorearse y adaptarse continuamente al uso cambiante del cliente, conforme se requiera. En esta organización uno a varios, solo existe un caso del software en operación en cada casillero, para que las mejoras frecuentes en el software están automáticamente e igualmente disponibles para cada inquilino. Cada casillero también contiene inquilinos múltiples, por lo que en lugar de permitir que los servidores inactivos dentro de cada casillero recolecten polvo, los servidores se maximizan de forma dinámica con base en la necesidad. En el modelo de un solo caso y de inquilinos múltiples, los usuarios pagan solamente por lo que utilizan, mientras que la escalabilidad se ajusta automáticamente con base en el uso real. Este modelo también tiene el beneficio adicional de una velocidad más rápida de despliegue y de siempre operar en la última versión de software. Por lo tanto, si el sitio de un usuario experimenta un aumento inesperado en el tráfico, los recursos se reparten de forma automática para que el sitio no experimente necesariamente un desempeño más lento. Sin embargo se debe hacer notar que las instalaciones de inquilinos múltiples que combinan datos de distintas compañías dentro de una aplicación hacen que la actualización sea más fácil y rápida, pero también abren la puerta a los errores de las compañías cruzadas en la seguridad de datos, corrupción o compromiso. Luego en esta serie de artículos se examinarán algunas variaciones de vendedores en arrendamiento múltiple, que dirigen los asuntos presentados anteriormente.

Otro problema con SaaS es que el único caso del software del modelo SaaS por lo general hace que la integración de aplicaciones dispares sea difícil, cuando se piensa acerca de un acercamiento más amplio que involucre procesos comerciales intra empresariales (y la profundidad asociada y capacidades funcionales más amplias). Por otro lado, con los modelos comerciales de licencia en premisa, los clientes pueden modificar de forma más factible su caso de aplicación de software local a una interfase con otro legado de aplicaciones. Esto no era posible con servicios hospedados de un solo caso. Para resolver el problema de la personalización e integración al legado de aplicaciones existentes, los vendedores de SaaS y las ASPs han estado viendo los servicios Web, pero pasará algún tiempo antes de que la tecnología esté lo suficientemente madura para ser capaz de reemplazar a los agentes de mensajes problemáticos y los centros de integración de los que las compañías aún dependen. Por lo tanto, por ahora, los agentes de mensajes y los centros de integración son todavía una mejor solución para el procesamiento de gran volumen que los servicios Web.

El impacto de servicios Web en SaaS

Sin embargo, al nivel más alto, SaaS debe ser entregado como un acercamiento de una arquitectura orientada al servicio (SOA) y debe cubrir los servicios Web. El beneficio clave de los servicios Web es que separa el uso de funcionalidad de la entrega de funcionalidad, donde la arquitectura de arrendamiento múltiple les permite a los usuarios personalizar sus páginas Web sin construir su propio código. Continuamente nuevas características y funcionalidad pueden estar disponibles, conforme las características de las mejores prácticas se identifiquen y estén disponibles. Para mayor información, consulte Understanding SOA, Web Services, BPM, BPEL, and More.

La integración por medio del código personalizado y del desarrollo con el tiempo será innecesario una vez que los servicios Web se conviertan en el método preferido para la integración con un sistema de etapa final o un servicio externo, y una vez que toda la funcionalidad pueda exponerse. Por ejemplo, los minoristas y los fabricantes pueden necesitar exponer la información de precios o inventario, o abrir un servicio Web para capturar órdenes. Ya existen algunas aplicaciones comerciales que pueden llamar una aplicación tercera diferente mientras preservan el contexto de la aplicación original subyacente. Con las tecnologías más nuevas disponibles, las compañías pueden literalmente escribir varias líneas de código para que una aplicación se comunique con otra.

El desarrollo de tecnologías, como servicios Web y estándares de transacciones de lenguaje extensible de marcas (XML), está haciendo que la interfase entre las aplicaciones de vendedores múltiples sea más factible. Por lo tanto, las compañías de hospedaje probablemente sean capaces de desarrollar interfases de aplicación estándar para la integración de aplicaciones. Sin embargo, en este momento, los servicios Web siguen compartiendo solo un pequeño pedazo de la integración, lo que significa que los vendedores exitosos y ASPs todavía deben ser capaces de proporcionar una gama completa de interfases que soportan no sólo los servicios Web, pero también el legado de protocolos de mensajes. Para habilitar el servicio uno a varios o de arrendamiento múltiple, los proveedores SaaS pueden asociarse con otros compañeros para entregar una oferta estándar que se personaliza por medio de integración dinámica y el acceso seguro a los módulos múltiples de aplicación, con la mínima personalización de la lógica central de la aplicación. Por el momento, el modelo comercial de servicio de software hospedado todavía aplica lo mejor a las aplicaciones que se pueden correr de forma aislada o con interfases limitadas o menos involucradas a las aplicaciones de terceros.

Esto hace que SaaS sea atractivo, ya que tiene costos de entrada más bajos, y si la compañía no se da cuenta del valor del software, siempre puede dejar de usarlo (y dejar de pagarlo). Al igual que en las licencias en premisa, este modelo proporciona una corriente estable de ingresos para el vendedor en forma de pagos mensuales recurrentes, pero, a diferencia de la licencia en premisa, este modelo requiere que el vendedor asuma el costo del hospedaje de la aplicación. Además de ser más fácil de accesar por medio de la Web, con lo que elimina varios de los costos dedicados a la red que los acuerdos anteriores de hospedaje involucraban, la nueva generación de soluciones SaaS sobrepasa las aplicaciones hospedadas del pasado al ser más sencilla de adquirir y de desplegar cada vez mas, conforme se requiere o en demanda.

Beneficios potenciales de SaaS

El modelo comercial de SaaS ofrece varias ventajas para el cliente y para el vendedor que compensa los altos costos de larga operación de este modelo. Al comprar un servicio de software (como opuesto a comprar una licencia de software), el cliente tiene pocos o ningún costo de adquisición inicial, ningún hardware o software que comprar, y ningún staff numeroso de soporte de tecnología de la información (IT) que contratar o entrenar. El costo de adquisición se reduce básicamente al costo del entrenamiento de los empleados en la aplicación, la configuración inicial de la aplicación, y de convertir o migrar los datos existentes.

El SaaS hospedado también es más fácil de operar, parcialmente porque la personalización es limitada, pero también porque no existe ningún hardware que comprar ni software que instalar. Además, no existe un software que manejar, arreglar o actualizar, ya que esto se convierte en la responsabilidad del vendedor. Los usuarios obtienen una aplicación semi personalizada sin tener que contratar ni una falange del staff de IT para que siga operando. Debido a que el vendedor o ASP está hospedando la aplicación, los clientes solamente ven un caso del software. Por otro lado, con el modelo en premisa, el software se distribuye al cliente y se instala en la computadora del cliente en una variedad de ambientes, fuera del control del proveedor de software. Una vez más, SaaS reduce las penosas actualizaciones, ya que los clientes permanecen automáticamente actuales en los lanzamientos, a pesar de gastar un mínimo esfuerzo en actualizaciones. Por lo tanto, los costos fijos tradicionales se convierten en contrapartes variables, ya que un cliente solo paga por el software que "consume". Esto puede requerir algunos nuevos acercamientos al presupuesto IT, pero debe reducir el gasto innecesario de software. Además, los clientes pueden empezar a preferir ser capaces de pagar por el uso, con tal de que sea controlable. Entre más puedan hacer que sus costos varíen, y se enlacen al volumen del negocio, serán más capaces de manejar sus estados de pérdida y ganancia (P&L).

Además, estas reducciones de costos pueden permitirle al vendedor cobrar más por un servicio de software que una licencia en premisa basada en el usuario. Además, el modelo SaaS reduce fuertemente los costos de cambio, y debe hacer que los proveedores de software sostengan niveles más altos de satisfacción del cliente y entregar una mejor funcionalidad del producto para asegurar una adopción más amplia del usuario. Debido a la existencia de sólo una instancia de la aplicación del software, con frecuencia el vendedor solamente tiene que soportar una plataforma de hardware y software, que reduce en gran medida a los costos del desarrollo. Los vendedores pueden ofrecer más soporte dirigido al cliente mientras se enfoca en una sola versión. Un solo caso, también significa que el vendedor puede introducir mejoras del software una por una, rompiendo el ciclo de actualizaciones y eliminando el costo que el ciclo genera. La entrega de SaaS le proporciona a los vendedores retroalimentación del cliente en tiempo real, y los vendedores astutos pueden seguir monitoreando el uso de su aplicación y aplicar esta introspección hacia mejoras de productos. En el lado del comprador, los bajos costos de adquisición de los servicios de software también hace que sea asequible por un mayor número de clientes prospecto. En especial, el hecho de que sea asequible le da a las compañías pequeñas la oportunidad de utilizar virtualmente las mismas soluciones que sus antepasados más grandes, y por lo tanto expande la oportunidad del vendedor para vender su servicio a un mayor número de clientes.

Informática en demanda (utilidad)

La última variación en los modelos comerciales hospedados está en la informática en demanda (utilidad) y la asignación de precios asociada. Esta es una tendencia que ha capturado la atención de una tecnología fuerte incluyendo IBM, Hewlett Packard (HP), Oracle, y Sun Microsystems. De igual forma que los servicios comunes de electricidad y agua, la informática en demanda les permite a los clientes comprar potencia de procesamiento e ingresar al software cuando sea necesario, y pagar con base en cuánto y qué tan seguido se utilizó el software. La clave para entregar software en demanda es una rejilla informática, que permite la asignación dinámica de los recursos de productos agregados para cubrir con la demanda cambiante La arquitectura del producto consiste en múltiples capas, incluyendo el hardware físico, la infraestructura de las aplicaciones empresariales y la interfase de usuario basada en la Web (UI), que están organizadas para ajustarse a los nuevos clientes, cambios en la demanda y fallas de los componentes. Entre cada una de estas capas están los habilitadores virtuales que permiten la combinación de recursos para ajustarse de forma dinámica. Por ejemplo, el almacenaje virtual es la unión de múltiples dispositivos de almacenaje de la red dentro de lo que parece ser una sola unidad de almacenaje. Este habilitador en demanda de almacenaje, que por lo general se implementa por medio de las aplicaciones de software, con frecuencia se utiliza en una red de área de almacenaje (SAN), una sub red de alta velocidad de dispositivos compartidos de almacenaje y hace que las tareas como archivar, respaldar y recuperar sean más fáciles y más rápidas.

Este nuevo modelo puede llegar a ser atractivo para las grandes organizaciones, aunque casi todas las aplicaciones iniciales hospedadas han estado dirigidas a los negocios pequeños y medianos (SMB). Negocios en demanda es el eslogan actual de IBM, que lo define para relacionarlo con negocios ágiles interconectados dentro de la cadena de suministro. El glosario en demanda de IBM proporciona la siguiente definición de los negocios en demanda:

Una compañía cuyos procesos comerciales, integrados por completo a lo largo de la compañía y con socios, proveedores y clientes clave, puede responder con flexibilidad y velocidad a cualquier demanda del cliente, oportunidad del mercado o amenaza externa. Un negocio en demanda tiene cuatro atributos principales: Es receptivo, variable, enfocado, resistente y está basado en la entrega flexible del software para fortalecer al negocio.

Con base en esta definición, en demanda incluye SaaS, pero abarca más procesos comerciales intrínsecos a lo largo de toda la compleja cadena de suministro. Actualmente, SaaS dirige pedazos de funcionalidad más simples, aunque entregados a través de un concepto en demanda (cuando se necesita). Todavía falta ver cómo se va a lograr el verdadero concepto comercial en demanda de IBM en las grandes compañías, ya que estas compañías usuarias más grandes tendrán que competir con base en la innovación de procesos comerciales en lugar de en fortalecer “los frutos restantes”. Sin embargo, la verdadera diferencia entre el competidor será difícil de lograr con las arquitecturas del producto de hoy en día, a menos que exista una inversión considerable en las aplicaciones complejas y su modificación.

En demanda también implica una informática ágil, donde se compra y se paga la potencia de procesamiento de acuerdo a la demanda. En este aspecto, el surgimiento de los conceptos SOA y el desarrollo de la informática virtual ha introducido la noción de una flexibilidad casi completa en términos de cuáles sistemas o servicios se utilizan. Los usuarios del sistema deben ser capaces de decidir qué tanta potencia utilizar y cómo varios usuarios tienen acceso al software, ya que con frecuencia, estos números cambian al minuto. Sin embargo, a pesar de tanta charla acerca de la facturación de pago por uso (PAYG), todavía es muy raro y posiblemente puede ser mejor aplicado en el marco final del mercado. Esto es en parte ya que estos sistemas utilizan técnicas relativamente simples. El costo capital inicial más alto de máquinas hacen que PAYG sea más atractivo para el proveedor y para el cliente, y las ventas de sistema final con frecuencia involucran un gran elemento de servicio. Los dos principales proveedores de sistema, IBM y Unisys, han sido capaces de “doblar” la potencia suministrada y medir de acuerdo al sobre aprovisionamiento de las máquinas suministradas. Cuando la demanda es alta en ciertos momentos, los procesadores inutilizados se prenden dinámicamente y el uso se mide de acuerdo a esto.

Sin embargo, el hecho sigue siendo que para la mayoría del mercado potencial, la facturación adecuada del procesamiento en demanda, aplicaciones y servicios ha sido un gran reto. En concreto, si algo que está disponible no se utiliza, entonces, cada vez más (y lógicamente), los clientes no esperan que se les cobre. Por otro lado, si algo se utiliza, ¿cómo se mide? ¿Qué pasa si la capacidad se localiza en una base provisional (o como latente para emergencias, y no se utiliza? ¿Cómo se les va a facturar a los usuarios? Aún más, la mayoría de las aplicaciones empresariales se utilizan de forma imprevisible, y las aplicaciones compuestas o muy integradas le añaden más complejidad. En el futuro, estas aplicaciones se harán cada vez más de componentes y servicios enlazados de forma dinámica, y algunos se utilizarán casi siempre, mientras otros sólo ocasionalmente. Para medir tal uso, uno puede prever motores centrales de facturación que pueden medir cientos de servicios, y que son similares a los sistemas actuales de facturación de los teléfonos celulares, que pueden medir las llamadas con base en el uso a través de una red de varios proveedores, pero este sistema todavía tiene que crearse.

Preocupaciones más comunes del modelo de hospedaje

Comenzando la lista de las dudas acerca de los modelos de hospedaje se encuentra la posibilidad de si las ofertas de hospedaje se pueden integrar de forma adecuada con las aplicaciones en premisa existentes. También existe escepticismo acerca de la utilidad de adaptar soluciones en demanda, SaaS u hospedadas a procesos comerciales y prácticas únicas, especialmente aquellas que requieren un cumplimiento estricto de las reglas. Por ejemplo, Salesforce.com y otras compañías SaaS (por lo general se identifican porque contienen la palabra sales o net dentro del nombre, consulte Las distintas alternativas de servicio de la gestión de las relaciones con los clientes) generalmente ofrecen buenas soluciones para operaciones comerciales estándar. Sin embargo, al utilizar una arquitectura de arrendamiento múltiple, que requiere volúmenes de clientes en una sola instancia de la base de datos, algunas veces no pueden darles a las compañías los tipos de diferenciadores que necesitan para incrementar las ventas y las ganancias para obtener participación en el mercado. Estos diferenciadores siguen la regla “80:20”, donde el 80 por ciento de la compañía es similar a su competidor y el 20 por ciento es lo que la diferencia. Es esta diferencia, que no puede proporcionar SaaS, que hará que las empresas sigan buscando vendedores tradicionales con cierta experiencia específica de la industria y huellas funcionales más amplias que puedan acomodarse a los procesos comerciales en evolución. Personalizar los nombres de los campos UI no cubrirán esta necesidad. Tampoco lo hará la habilidad del usuario para escribir Java Script, para poner el localizador universal de recursos (URL) para la escritura en un campo personalizado, o el uso de acceso de tabulador y hojas de estilo, a los que Salesforce.com se refiere como trabajo de personalización.

Las empresas también quieren más control de sus aplicaciones, ya que necesitan estar cambiando constantemente las configuraciones, añadiendo nuevos productos, desarrollando una mayor integración entre sus sistemas, e introduciendo procesos comerciales de la mejor calidad. Asimismo, varios directores IT no estarán contentos con la idea de ceder partes de su reino IT, y de tener que depender de la habilidad de un anfitrión externo para correr de forma impecable sus centros de datos, incluso si el anfitrión es un negocio confiable. Estos problemas y una conciencia de mercado en ciernes puede explicar encontrar un reciente estudio que afirma que más del 60 por ciento de las empresas actualmente prefieren el modelo de licencia perpetua en premisa a las opciones basadas en suscripción.

El modelo de pago más común hoy en día es que el cliente pague por una licencia de software a través de una cuota fija con base en la potencia de procesamiento de la máquina (o máquinas) que se utiliza. Un acercamiento alternativo muy utilizado es que la empresa usuaria (concesionario) pague una cuota fija de acuerdo al número de usuarios (o asientos) que ingresan al software. Para ser justos, ambos acercamientos son relativamente estables, y le permiten al cliente presupuestar utilizando una fórmula, mientras que el vendedor recibe gran parte del ingreso de la licencia, con un flujo estable de ingreso por mantenimiento anual (por lo general del 15 al 20 por ciento) a partir de entonces. Es un modelo estable y rentable que los clientes y los inversionistas entienden, y los hábitos son difíciles de romper.

Otro inconveniente de los modelos hospedados es el costo a largo plazo del arrendamiento del servicio para los clientes. Uno de los principales beneficios del hospedaje es la negociación inicial de los costos iniciales asociados con la rápida implementación de un sistema de producción. Sin embargo, después de cierto periodo de tiempo, el sistema suscrito costará más que un sistema de producción interno. El atractivo de los modelos de hospedaje es por lo tanto la gratificación inmediata aunada a la reducción de los dolores financieros iniciales.

Con esto concluye la segunda de cuatro partes que conforman esta serie, El software como un servicio está ganando terreno. En la primera parte se habló acerca del surgimiento de SaaS. La tercera y la cuarta parte presentarán a los vendedores y proporcionarán recomendaciones para el usuario.