La adopción de software brindado como servicio ha crecido en los últimos años. Según Gartner Inc. para el año 2010 más del 30% de los proveedores de software ofrecerán al menos alguna de sus aplicaciones bajo este modelo. Por otra parte, las empresas que brindan plataforma, desde Microsoft, Google hasta Amazon, están invirtiendo fuertemente y han comenzado a virar lentamente su maquinaria hacia este modelo. Otras empresas como salesforce.com han demostrado resultados exitosos basando su negocio exclusivamente en este modelo. No quedan dudas que el Software como Servicio ganó y seguirá ganando aceptación, sin embargo, ¿está la industria preparada para adoptar este modelo y hacer frente a esta demanda? ¿De qué se trata este modelo exactamente desde la perspectiva del productor de software? ¿Cómo se compone un proyecto basado en software como servicio? Esta tesis trata de responder estas preguntas definiendo un modelo y un body of knowledge para enfrentar este tipo de proyectos.
Prólogo
Mi interés por Software como Servicio (SaaS) comenzó a principios del año 2006 en un viaje a Microsoft Corp. En búsqueda de un tema interesante para elaborar mi tesis de grado, comencé a indagar y un colega me comentó sobre un nuevo modelo de distribución de software. Luego de unos meses, Alejandro Jack, mi manager, me puso en contacto con John Devadoss, gerente del grupo de arquitectura estratégica (AST) de Microsoft. Dentro de este grupo trabajan Gianpaolo Carraro, Eugenio Pace y Fred Chong encargados entre otras cosas de investigar el modelo Software como Servicio del punto de vista arquitectónico. Como parte de este desafío, el grupo establece relaciones con clientes interesados en este modelo y con los grupos de producto identificando gaps en la plataforma con el objetivo de proveer feedback. El grupo publica numerosos papers cubriendo esta área también y realiza pruebas de concepto utilizando los productos de Microsoft. Durante estos años colaboré con este grupo en diferentes proyectos. Participé en la construcción y dictado de workshops y vi madurar el concepto de Software como Servicio desde sus etapas iniciales donde se trataba de una incipiente modalidad hasta la actualidad donde está siendo adoptado por la industria.
Introducción
En los primeros días de la industrialización, las fábricas desarrollaban su propia fuente de energía. La electricidad era un diferenciador para las industrias: aquellas que la tenían eran superiores a aquellas que no. Sin embargo, el costo de instalación y mantenimiento que tenían que afrontar por tener su propia fuente de energía era demasiado alto comparado con el beneficio asociado. Con el tiempo, empujados por la necesidad de una masa crítica de la industria y una tecnología más madura, comenzaron a surgir proveedores especializados. Este proceso culminó con la invención de la electricidad, la forma más versátil de energía conocida por el hombre. El diferenciador dejó de existir como tal y entonces tuvo sentido recurrir a un proveedor externo. Las industrias podrían consumir toda la energía que ellas quisiesen, cuando la necesitasen y pagar solo por lo que usasen. La energía se había convertido en un servicio [Factor, 2001].
Si extrapolamos esta línea de evolución al software, la idea de brindar un software como un servicio no es tan ilógica. En lugar de tener que adquirir o desarrollar, instalar y mantener un software, simplemente las empresas lo contratarían y lo utilizarían.
Sin embargo, prestar un servicio en torno a una aplicación de software es algo más complejo que prestar un servicio como el agua, la electricidad o el cable. La electricidad se puede definir fácilmente: 110V/60 Hz en Estados Unidos o 220V/50Hz en Europa o Argentina. El consumidor solo precisa un conector y a lo sumo un transformador. En cambio en la joven industria del software, si bien existen estándares maduros, la interacción entre estos es más compleja y la superficie a resolver es mucho mayor. Esto trae aparejado una serie de dificultades: interoperabilidad, confianza, variabilidad de requerimientos, escalabilidad, seguridad, monitoreo de SLAs, monetización, acceso fuera de línea, entre otros.
No obstante, ciertas funciones de software son más fáciles de ofrecer como servicio que otras: todo aquello que no es parte del núcleo o no es un diferenciador para una empresa es susceptible de ser consumido como servicio. Entre los ejemplos más comunes se encuentra el e-mail.
Software como Servicio (Software as a Service en inglés) es el término con el cual se da a conocer hoy en día esta nueva tendencia de software consumido como si fuera un servicio y cuenta con implementaciones como el caso de Salesforce.com1 (CRM) o Amazon Web Services2. Las grandes empresas de software (por ejemplo Microsoft, Google, IBM) comenzaron a plantearse este modelo de servicios como parte de su estrategia esencial y se encuentran activamente desarrollando productos, frameworks y servicios de distinta granularidad.
Motivación
En los últimos 20 años la tecnología de información comenzó a jugar un papel muy importante en las empresas. Hoy en día una compañía que no destina recursos a IT corre con una desventaja muy grande para desarrollar y expandir su negocio. Es por eso que la mayoría utiliza un software que ayude en la toma de decisiones, manejo de información y registro de transacciones, entre otras cosas. Este software, la mayoría de las veces se instala y se mantiene en la empresa, y se lo denomina "software on-premise" 3. Esta parece ser una opción natural para él o las personas que tomen las decisiones relacionadas con tecnología dentro de una empresa. Sin embargo, a la hora de evaluar el costo-beneficio, instalar un software "on-premise" implica adquirir una infraestructura de hardware, comprar licencias de software de base, contar con personal calificado para que lo administre y mantenga, y muchos otros costos indirectos. El modelo de software brindado como servicio, en pocas palabras, cambia el método de distribución y monetización tradicional ofreciéndolo como una utilidad.
Durante el desarrollo de esta tesis se enumerarán las razones por las cuales Software como Servicio puede ser una alternativa atractiva para las empresas y por qué el modelo puede tener potencial. Estas razones se pueden encontrar en internet en pocos segundos con una simple búsqueda en Google o Wikipedia. Si bien los beneficios que trae este nuevo modelo de distribución son fácilmente visibles, el grueso de la información está dirigido al consumidor y no al proveedor de software. Construir un software y brindarlo como un servicio es un terreno que se encuentra poco explorado aún. Existen implementaciones exitosas pero hay poca información, ya sea en internet, en publicaciones o papers sobre cómo construir este tipo de software y los desafíos técnicos intrínsecos en el modelo. Una de las razones puede ser que el tema es relativamente nuevo y el mercado está enfocado en atraer la demanda y no la oferta. Si la tecnología logra pasar al mainstream, cientos de proveedores independientes de software (ISVs) y empresas se enfrentarán con el desafío de construir y encarar proyectos con estas características. Es por eso que este trabajo trata de brindar un panorama holístico que ayude a empresas a abordar el Software como Servicio.
Estructura de la tesis
Este trabajo comienza mencionando los antecedentes del modelo (5.1 Antecedentes), definiendo los roles y el ecosistema dentro del cual se encuadra Software como Servicio (5.2Definición de Software as a Service y 5.3 Roles y Ecosistema). Se realiza el análisis de adopción y difusión del modelo basado en la teoría de difusión de innovaciones (5.4 Adopción y Difusión) para luego enunciar el problema que se quiere atacar (6 Definición del Problema). El desarrollo y contribución principal se encuentra en la sección 7 Solución propuesta. Durante la primera parte se realiza un análisis del dominio de Software como Servicio (7.1 Análisis de Dominio) identificando y definiendo las características que exhiben las principales soluciones y productos en el mercado. Estas características serán luego encuadradas en un modelo de características (7.2 Modelo de Características) o feature model [Kang K., 1990]. El modelo está desarrollado en un nivel conceptual y un nivel de implementación. El primero explora las características de manera agnóstica (7.3 Capacidades) y el segundo propone implementaciones y tecnologías alternativas relacionadas con la capacidad conceptual (7.4 Implementación). Por último, se aplica el modelo en una aplicación de ejemplo (8 Aplicación del modelo), se enumeran las conclusiones (9 Conclusiones) y las líneas de investigación abiertas para futuros trabajos (10 Futuras líneas de investigación).
Estado de la cuestión
Antecedentes
Tercerización
Un siglo atrás, la mayoría de la población mundial trabajaba en el campo. Durante las buenas épocas había mucha comida. Sin embargo, las épocas malas significaban hambre y muerte como ocurrió en la gran hambruna irlandesa entre 1845 y 1849. Hoy en día el empleo relacionado con la agricultura representa un 5% en economías avanzadas. A pesar de este porcentaje tan bajo, no hay problemas masivos de alimentación en este tipo de economías. La diferencia, radica en el aumento de productividad que ocurrió en la industria agrícola y más recientemente en la industria manufacturera. Este aumento de productividad se dio gracias a la lenta migración de los granjeros a industrias especializadas que soportan la producción agrícola: equipamiento, fertilizante, pesticidas, prácticas de manejo de las tierras, semillas superiores, servicios de transporte, servicios de combustible, servicios de soporte del gobierno, y más. En resumen, una gran cantidad de conocimiento embebido en instituciones, industrias, profesiones y tecnologías existen para soportar a un grupo pequeño de granjeros que abastecen a todo el mundo. Con el tiempo, la división del trabajo y la especialización fueron creciendo [A research manifesto for services science, 2006].
La especialización se puede asociar fácilmente a la tercerización. La principal diferencia radica en que el primero es un concepto económico que explica como el mercado fuerza la división del trabajo creando economías más saludables. La tercerización en cambio es un concepto utilizado en el ámbito de negocios y contable. Es un concepto utilitario que se define como "la transferencia de un servicio interno a un proveedor externo"4.
La tercerización tiende a bajar los costos debido a la especialización, es por eso que es una práctica muy utilizada en los negocios. Existen diversos ejemplos de tercerización en la industria. Las auto partes en la fabricación de un auto, la prefabricación de ladrillos en la construcción de casas y edificios, etc. Para el común de la gente, la tercerización es aún más evidente. De hecho, ninguno cosecha trigo y después hace el pan, simplemente lo compran en la panadería; o no cosechan algodón para hacer sus prendas.
En las empresas, históricamente, la tercerización más común es la limpieza, el mantenimiento de las oficinas, la preparación de comida, etc. Otros casos más complejos pueden ser las áreas de soporte como legales, contaduría, auditorías, comunicaciones, publicidad, etc.
¿Por que conviene comprar servicios a otras empresas en lugar de hacerlo dentro la propia? Porque los proveedores de estos servicios se especializaron y aprendieron como brindar el servicio con calidad y a precio competitivo al mismo tiempo. De hecho, muchas veces para ser más eficientes recurren a las redes y computadoras para automatizar muchas de sus funciones y crean o compran aplicaciones que reutilizan para todos sus clientes obteniendo un margen operativo más alto. Por otro lado las áreas que tercerizan las empresas suelen ser áreas de poco o muy bajo aporte al "núcleo del negocio". Son áreas necesarias, pero no suficientes de la actividad de una empresa determinada. Por ejemplo, Microsoft no teceriza el desarrollo de software de sus productos más significativos, porque ese es su "núcleo de negocio". Sin embargo, si terceriza el mantenimiento de sus edificios.
Las empresas de tecnología son uno de los servicios más comunes disponibles hoy en día. Es más, si una empresa de energía puede construir la planta, instalar generadores, desarrollar las redes de distribución y proveer energía a millones de personas, ¿por qué una empresa de servicios de IT no puede construir su propio datacenter, comprar e instalar las computadoras, desplegar una aplicación de software y proveer el software como servicio a sus clientes? Si puede, y de hecho varias empresas lo están haciendo hace tiempo.
Contexto histórico
En 1961, John McCarthy5, fue el primero en sugerir públicamente (en un discurso dado en el marco de celebración del centenario del MIT) que la tecnología de tiempo compartido de la computadora podría conducir a un futuro en el que el poder de cómputo e incluso aplicaciones específicas podrían ser vendidas como un servicio (como el agua o la electricidad). La idea de una computadora o una utilidad informática era muy popular a fines de la década del 60. El mainframe brindaba servicios de cómputo y los usuarios en sus terminales accedían a los programas que este brindaba. Estos programas estaban disponibles "on demand". Era el sueño de cualquier administrador de IT, tener control absoluto y centralizado, sabiendo exactamente qué programas existían y qué usuarios podían acceder a los mismos con una interfaz homogénea. Sin embargo, hacia mediados de los 70 se volvió claro que el hardware, software y las tecnologías de telecomunicación simplemente no estaban preparados para la potencial demanda [Greschler, y otros, 2002].
A principios de los "80, surgió la PC y los usuarios descubrieron que podían controlar su entorno. Podrían elegir que software correr e incluso modificar el estilo y color de su interfaz. Al funcionar el software de forma local nadie tenía problemas de performance que traía el acceso concurrente al mainframe. Sin embargo surgió otro problema: los usuarios se convirtieron en sus propios administradores. Al no estar entrenados para esta tarea y con el advenimiento de internet y problemas serios como los virus informáticos, no deja de ser llamativo que la principal fuente de ingresos pasó a ser "soporte y mantenimiento".
Finalmente, en los últimos años convergieron una serie de factores que causaron el retorno del concepto del software como servicio [Greschler, y otros, 2002]:
La dificultad que han tenido los usuarios finales para manejar productos de software
La dificultad que ha tenido IT para manejar productos de software
La dificultad que han tenido los ISVs (Vendedores de Software Independientes) para vender y distribuir productos de software
Los cambios en la tecnología
La llegada de los Application Service Provider (ASP)
Los primeros dos puntos fueron expuestos anteriormente. Los otros tres merecen un tratamiento más detallado.
Los ISVs desean evolucionar a nuevos modelos de negocios basados en subscripción y pay-per-use6. Su actual canal de distribución es difícil de mantener y la piratería preocupa cada vez más, sobre todo en Asia y América Latina. El usuario desea poder utilizar una aplicación desde cualquier computadora y dispositivo e incluso las empresas desean "contratar" una aplicación para un proyecto específico y pagar solo por el uso que se le da en ese período.
En cuanto a los cambios en la tecnología, estos abarcan tanto hardware como software de base. Las redes de alta velocidad o banda ancha han proliferado. En Estados Unidos, en el 2005, más del 55% de las conexiones de internet eran de banda ancha. En el 2006 este número creció a 70% y para mayo de 2008 el 90% contaba con conexión de banda ancha [Nielsen Online, 2008]. La web se transformó en un componente casi obligatorio para cualquier empresa. Las herramientas para desarrollar aplicaciones son mucho más completas y los estándares como HTTP y web services están maduros y adoptados por las plataformas más utilizadas (.NET, Java, PHP). La web ha evolucionado de ser una gran biblioteca de solo lectura a ser un medio mucho más natural donde la gente se relaciona, se comunica, interactúa, aprende, juega, compra, vende y socializa [O'Reilly, 2005].
Por último, las empresas comenzaron a confiar en las compañías de web hosting (alojamiento web) para exponer sitios y aplicaciones. Más tarde surgió la idea de los Application Service Providers (ASP) en donde parte o toda la administración de IT se tercerizaría a proveedores especializados.
Estos proveedores existieron durante la era de la burbuja ".com" a fines de los "90 y principios del 2000, sin embargo muchos de ellos fracasaron ya que lo único que ofrecían eran datacenters gigantescos para albergar aplicaciones existentes que no fueron diseñadas para escalar. En un estudio realizado en el año 2003, se reveló que de las 424 compañías relevadas, 203 habían fallado, 40 habían sido compradas y 8 se habían asociado. Solo 173 de 424 sobrevivieron [Bhavini y otros, 2003].
En este contexto surge el modelo de Software as a Service cuyas características serán definidas en la siguiente sección.
Definición de Software as a Service
Software como Servicio en su definición más ortodoxa es un modelo de distribución de software mediante el cual una aplicación es ofrecida a múltiples clientes y es accesible a través de la red (ej.: internet).
Las principales características del modelo según [IDC, 2008] son:
El software es accesible, manejado y comercializado vía red
El mantenimiento y actividades relacionadas con el software se realiza n desde un lugar centralizado en lugar de hacerlo en cada cliente, permitiendo a estos acceder a las aplicaciones vía la red
La aplicación es distribuida típicamente bajo el modelo de uno-a-muchos, incluyendo su arquitectura, management, precio y partnering
Generalmente se basa en un modelo de comercialización en el cual no hay un costo inicial, sino que un pago por suscripción o por utilización en el cual no se diferencia la licencia del software del alojamiento del mismo.
La figura a continuación muestra algunas características de Software como Servicio en comparación con Application Service Provider y tercerización tradicional de una aplicación [Forrester Research, 2008]:
Figura 1 – Software como Servicio vs Application Service Provider vs outsourcing de aplicaciones [Forrester Research, 2008]
Roles y Ecosistema
Construir, Ejecutar, Consumir y Comercializar
Dentro del ecosistema del modelo Software como Servicio es posible definir un conjunto de roles. Estos roles definen responsabilidades que pueden ser ejecutadas por un mismo actor o diferentes actores. La siguiente figura define los roles: construir, ejecutar, consumir y comercializar.
Figura 2 – Roles dentro del modelo de Software como Servicio [Carraro y otros, 2007]
Construir
La tarea principal de este rol es construir el software aportando el conocimiento del dominio específico. Por ejemplo, una empresa con conocimientos del dominio financiero construye una aplicación para el manejo de flujo de dinero. Esta empresa tiene el conocimiento necesario para mapear los requerimientos del mundo financiero a una aplicación que automatice las tareas y reportes relacionados con el manejo del flujo de dinero. Sus principales preocupaciones están relacionadas con la arquitectura de la aplicación, la lógica y reglas de negocios, el modelo de datos, etc. Idealmente, esto debería ser ortogonal al modelo de comercialización por suscripción o una licencia perpetua o al hecho de distribuir la aplicación a múltiples clientes por la web o enlatada. Los requerimientos relacionados al negocio en sí, se mantienen inalterables. Sin embargo, tendrá que realizar ciertas optimizaciones relacionadas con el modelo. Un ejemplo de esto es multi tenancy que es la capacidad de utilizar la misma infraestructura (código base, base de datos, etc.) para servir a múltiples clientes. En este rol están los proveedores independientes de software (ISV), empresas como salesforce.com o cualquier empresa que conozca de un negocio específico a modelar y esté interesada en construir el software con las características del modelo.
Ejecutar
En el rol de ejecución la tarea principal es proveer plataforma e infraestructura para la ejecución de Software como Servicio. Se puede trazar una analogía con los proveedores de alojamiento web que brindan servicios a empresas que quieren exponer y ejecutar sus aplicaciones a través de la web. La diferencia en este tipo de ejecución es que mientras el proveedor de alojamiento solo ofrece el cable de red, el ancho de banda, un servidor y espacio en disco el rol de ejecución en Software como Servicio tiene más responsabilidades. Entre ellas se puede nombrar escalabilidad a demanda, manejo de recursos, acuerdos de nivel de servicio y un conjunto de componentes optimizados especialmente para la plataforma. En este rol hay algunos proveedores especializados que ofrecen infraestructura como Amazon Web Services y en un nivel de abstracción más alto proveedores de plataforma como Google App Engine.
Consumir
Consumir Software como Servicio no debería ser muy diferente a consumir cualquier otra aplicación. Es decir, el consumidor no tiene porque interesarse en la forma en que el proveedor distribuye su aplicación o si es multi tenant o no. En última instancia, el consumidor se interesa en las características del software y si lo ayuda o no a su negocio. Las preocupaciones en este contexto son: cómo se integra el software al conjunto de aplicaciones existentes, cuál es el mecanismo de seguridad y como interactúa con los mecanismos de la empresa, si se está cumpliendo o no con el nivel de servicio acordado, etc. En el rol de consumidor se encuentra cualquier organización que desee automatizar una de sus capacidades de negocio. Las opciones eran construir o comprar, ahora bajo este modelo se agrega una tercera opción: alquilar.
Comercializar
La comercialización es la actividad relacionada con sacar rédito económico del software. El rol de comercializador generalmente lo toma el mismo que construye, no obstante la especialización también lleva a que haya empresas dedicadas, exclusivamente o no, a monetizar una aplicación brindada como un servicio. Por ejemplo, una aplicación con un tráfico importante puede no cobrarles a los usuarios pero ganar plata de los avisos publicitarios de Google AdSense. Es decir, Google toma el rol de comercializador. Los tipos de comercialización más comunes son: por suscripción, por utilización y por publicidad. Dentro del modelo de suscripción el más utilizado es "por mes por usuario". También es el menos intrusivo a la aplicación ya que puede manejarse totalmente separado (aunque hay beneficios en la integración). Este modelo es generalmente utilizado en aplicaciones que brindan cierta funcionalidad de negocios. El modelo por utilización es más granular y quizás más flexible. Se paga por lo que se usa. Es recomendable cuando sea simple medir el uso de los recursos y generar un margen por arriba del recurso. Por último el modelo basado en publicidad utiliza una plataforma para mostrar publicidad a cambio de un monto por cada impresión o click. Este modelo se puede utilizar en sitios con mucho tráfico.
A continuación se ilustran 6 ejemplos en donde se diferencian los roles en cada uno.
Figura 3 – Ejemplos de empresas tomando diferentes roles dentro del modelo El primer ejemplo es el CRM de salesforce.com. Esta es una aplicación para manejar las oportunidades y los clientes y está ofrecida como servicio. Salesforce construye, ejecuta y comercializa. Es decir, conoce el dominio de CRM y construyó una aplicación multi tenant que luego desplegó en su datacenter y ejecuta por su cuenta y por último se encarga de la comercialización bajo el modelo de suscripción.
El segundo ejemplo es Motorola, una empresa que "alquila" el software de CRM realizado por salesforce.com. El rol de Motorola en este escenario es solamente consumir la aplicación de CRM, no construye, ni comercializa ni corre la aplicación [Salesforce.com].
El tercer ejemplo es Amazon Web Services. Amazon brinda servicios de infraestructura también llamado utility computing, como almacenamiento, poder de procesamiento y hasta una cola de mensajería accesible por web. Todos estos recursos infinitamente escalables. En este caso Amazon ejecuta, es decir tiene la plataforma para construir sobre y comercializa, cobra por la utilización de los recursos.
El caso de New York Times que utiliza Amazon Web Services, no es únicamente consumidor del servicio sino que además construye sobre su infraestructura. Por ejemplo, construyó una solución sobre Amazon S3 y EC2 para digitalizar todos los diarios desde el año 1851 a 1922 [Gottfrid, 2007].
Por último, una organización puede estar interesada en crear su propia plataforma corporativa basada en un modelo de Software como Servicio. Para trazar una analogía, sería similar al concepto de intranet e internet. Es una versión "privada" a una escala menor pero los mismos conceptos. En ese caso, la organización construye, ejecuta, consume y opcionalmente comercializa la plataforma. Esto también es conocido como "IntraSaaS".
Adopción y Difusión
Habiendo definido el modelo de Software como Servicio, se ensayará un análisis de adopción y difusión tomando datos hasta Agosto de 2008 con el objetivo de situar está innovación en el ciclo de vida de adopción tecnológica. El análisis estará enmarcado en la teoría de difusión de innovaciones [Rogers, 2003].
El ciclo de vida de adopción de tecnología es un modelo sociológico, originalmente desarrollado por Joe Bohlen y George Beal en 1957. El objetivo era registrar los patrones de compra de semillas de maíz de los granjeros. Seis años más tarde Everret Rogers expandió el uso de este modelo en su libro Difusión de Innovaciones [Rogers, 2003].
El modelo de ciclo de vida de adopción tecnológica describe la aceptación de un nuevo producto o innovación de acuerdo a las características demográficas y psicológicas definidas por los grupos de adopción. El proceso de adopción a lo largo del tiempo se ilustra como una curva de campana, ubicando a los innovadores, tomando el riesgo más grande, luego los que adoptan tempranamente que buscan una ventaja competitiva también tomando riesgo. Cuando se percibe el valor real que aporta la tecnología en cuestión, la mayoría temprana adopta. La mayoría tardía son más cautelosos y los rezagados adoptan cuando es realmente barato y poco riesgo.
Figura 4 – Grafico de campana del modelo de ciclo de vida de adopción tecnológica [Rogers, 2003] Con el objetivo de analizar y entender la adopción de Software como Servicio y enmarcarlo en un grafico de campana de ciclo de vida adopción tecnológica, se analizarán encuestas y reportes relacionados con Software como Servicio de las principales agencias del mundo.
5.4.1 Gartner Inc. Gartner realiza una vez al año un reporte denominado Hype Cycle. Este modelo representa la evolución de lo que denomina visibilidad de una tecnología emergente (o expectativas despertadas por esa tecnología) en función del tiempo. Una evolución que progresa desde un entusiasmo exagerado, pasando por un período de desilusión hasta una eventual comprensión de la relevancia de la tecnología y de su papel en un mercado o dominio. El modelo se justifica por la influencia de dos fuerzas principales que conforman las expectativas que se crean alrededor de una nueva tecnología:
el ruido de comunicación (noticias, publicidad, etc.) sobre dicha tecnología, en una primera instancia
la madurez de la tecnología (desde un punto de vista técnico y de negocio), en una segunda instancia
El Hype Cycle es más útil desde la perspectiva del comprador de tecnología (no del proveedor), tiene un carácter descriptivo y su utilidad predictiva y de definición de planes de acción es menor. Sin embargo, es una fuente de información relevante para la industria.
El reporte de Hype Cycle Software como Servicio del año 2008 de Gartner [Gartner Inc., 2008], define 29 categorías relacionadas con el modelo Software como Servicio. Estas categorías son:
El gráfico de Hype Cycle se ve a continuación:
Figura 5 – Hype Cycle de Software como Servicio [Gartner Inc., 2008] Luego de un análisis más detallado del reporte se puede apreciar que dentro del tipo de software que llegó al "slope of enlightment" (cuando la industria comienza a encontrar el valor a la tecnología) se encuentran aquellas aplicaciones que no son del núcleo del negocio pero son necesarias (E-mail, procuración, reclutamiento, integración, etc).
Otra característica de este reporte es que brinda información relacionada con la madurez de la tecnología.
Figura 6 – Gráficos relacionados con el reporte Hype Cycle SaaS de Gartner. Gartner relaciona la etapa embriónica con actividad en laboratorios. La etapa emergente es la primera generación de producto con pilotos e implementaciones de líderes en la industria. En la etapa adolescente las capacidades de la tecnología están maduras, se trata de una segunda generación, existe un entendimiento y comienzan a aparecer los que adoptan de forma temprana. La tecnología ya está probada y la adopción evoluciona rápidamente en la etapa de adopción temprana. Luego, en la etapa de adopción madura, la tecnología es robusta, no se percibe evolución en los proveedores ni en la tecnología y existen varios proveedores dominantes. Por último, la etapa legacy, la ganancia está dada por el mantenimiento y el costo de migración es lo que impide el reemplazo por otra tecnología.
Los números arrojan que un 50% de las diferentes ramas del mercado relacionado con Software como Servicio está en etapa embriónica o emergente, con solo un 10% en etapa embriónica. El otro 50% está en etapa adolescente, adopción temprana o madura. No existe ninguna en modo legacy.
Por otro lado la mayoría de las ramas del mercado van a ser adoptadas por el mainstream dentro de 2 a 5 años. Solo una llegará a ser adoptada en menos de 2 años y el 33% restante dentro de 5 a 10 años. Es decir, según Gartner, recién en los próximos 3 a 6 años habrá una oferta de aplicaciones Software como Servicio insertada en el mercado mainstream.
La adopción de software brindado como servicio ha crecido en los últimos años. Según Gartner Inc., para el 2009, 100% de las empresas de servicios de IT más relevantes de la industria (tier 1) van a ofrecer consultoría relacionada con Software como Servicio. Para el 2010, el 15% de las grandes corporaciones habrá empezado a reemplazar su ERP con soluciones basadas en Service Oriented Architecture y Software como Servicio. Por último, un dato relevante, es que para el 2012, más del 33% de los ISVs van a ofrecer algunas de sus aplicaciones bajo el modelo de Software como Servicio [Gartner Inc., 2008].
Forrester
Forrester Research evidencia el creciente interés en este modelo comparando encuestas de 2006 y 2007 a grandes, medianas y pequeñas empresas [Forrester Research, 2008]. La pregunta que plantea la encuesta es "¿Cuán interesado está en adoptar Software como Servicio?". Del total de encuestados (1025 empresas de Estados Unidos y Europa), un 10% a un 20% están usando actualmente y la tendencia marca que la adopción se da en empresas más grandes. En todos los casos se incrementa el porcentaje en la categoría de "usando actualmente" y "muy interesado pero sin planes de adoptar" de 2006 a 2007.
Figura 7 – Forrester muestra el interes en el modelo comparando 2006 y 2007 [Forrester Research, 2008]
Saugatuck
De acuerdo a una encuesta realizada por Saugatuck Technology con un muestreo de 418 empresas [Saugatuck Technology, 2008], un 32% de los encuestados está utilizando Software como Servicio, un 43% lo está analizando y un 15% no planea utilizar.
Figura 8 – Adopción de SaaS [Saugatuck Technology, 2008] Del 15% que no planea usar, solo el 4% corresponde a las empresas con más de 5000 empleados. En empresas medianas la adopción es más cautelosa, más de 20% no planea usar. Los números son similares en empresas más pequeñas, 18%. Por otro lado, hay un porcentaje alto de empresas (más del 40% en todos los segmentos menos en empresas de 100 a 499 empleados) que están analizando el modelo. Estos podrían representar la mayoría temprana que no toma la decisión hasta que no estén seguros del retorno que les traiga.
Figura 9 – Encuesta sobre la falta de adopción de SaaS separada por cantidad de empleados [Saugatuck Technology, 2008]
Plataforma
Por otra parte, las empresas que brindan plataforma, desde Microsoft, Google hasta SAP, están invirtiendo fuertemente y han comenzado a virar lentamente su maquinaria hacia este modelo. Ray Ozzie, el reemplazo de Bill Gates luego de su retiro, distribuyó un memo en Ocutbre de 2005 llamado "The Internet Services Disruption" [Ozzie, 2005] en donde anuncia el inicio del ciclo de producto más grande de la historia de la compañía, esta vez relacionado con "service-enabled software". Amazon desde el año 2006 que abrió su plataforma al mundo ofreciendo servicios de almacenamiento, procesamiento, mensajería bajo el nombre de Amazon Web Services y el modelo de monetización de Software como Servicio, siendo hoy uno de los lideres en el mercado. Google se concentra en el segmento de consumidores y agranda la oferta de software ofrecido como servicio abriendo su plataforma con ofrecimientos como Google App Engine.
En resumen, las grandes empresas de plataforma están apostando al futuro del Software como Servicio.
Conclusión
A partir del análisis de diferentes reportes y encuestas y de mis propias percepciones nutridas desde los inicios del año 2006 cuando decidí realizar esta tesis, mi opinión es que a la fecha (Agosto de 2008) el mercado de Software como Servicio está en una etapa de adopción temprana (early adopters) casi llegando a la mayoría temprana (early majority), la tecnología está cruzando el abismo (crossing the chasm) [Moore, 1991]. Esta apreciación tiene en cuenta a todos los diferentes tipos de aplicaciones de Software como Servicio. Vale aclarar que ciertos tipos de aplicaciones están más maduras que otras y podrían estar en otras etapas de adopción como el caso del e-mail, CRM y procuración.
La primera ola de innovación comenzó en el año 2001. En ese momento el término Software como Servicio era nuevo en la industria y venía a reemplazar el viejo Application Service Provider (ASP) que no había tenido la adopción esperada. Software como Servicio fue más aceptado por el mercado y algunos proveedores ex ASP y otros nuevos comenzaron a ofrecer sus servicios bajo este modelo. A partir de fines del año 2005 y principios de 2006 el término SaaS se hizo mucho más conocido gracias a implementaciones exitosas que surgieron en la etapa de innovación, como salesforce.com y Amazon Web Services y al avance notable de las redes de banda ancha y la tecnología. En ese momento fue cuando comenzó la etapa de adopción temprana y de a poco comenzaron a aparecer los grandes jugadores de la industria, Microsoft, Google, IBM, etc. Al día de hoy existen más de 3500 soluciones basadas en el modelo, según un directorio independiente de aplicaciones Software como Servicio (saas-showplace.com).
En resumen, Software como Servicio pasó de ser adoptado solo por los innovadores y los early adopters. Con un promedio del 30% de adopción por parte de las empresas pequeñas, medianas y grandes de acuerdo a los diferentes reportes de las consultoras mencionadas anteriormente y un mercado con un 50% de proveedores en un nivel de madurez medio alto y un 50% en niveles embriónicos y emergentes, la tecnología está atravesando la barrera para llegar a ser adoptado por el mainstream. Las empresas que adoptan elijen aplicaciones que no son de misión crítica para su negocio y que no tienen requerimientos de integración complejos.
Figura 10 – Ciclo de vida de adopción y donde se encuentra Software como Servicio a mitades del año 2008
Barreras para la adopción
Las barreras para la adopción hoy en día por parte de los consumidores son:
Integración y customización. según la encuesta de Forrester, la integración es el tema numero uno nombrado por los encuestados de norte América y Europa con un 65% argumentando que la integración es la razón clave por la cual no consideran Software como Servicio. Los proveedores avanzaron en los desafíos relacionados con la customización e integración de Software como Servicio. Si bien la mayoría de ellos ofrecen APIs basada en web services y exportación de datos, el consumidor todavía percibe que posee más control utilizando las aplicaciones tradicionales.
Costo total de propiedad (TCO) del modelo por subscripción versus el modelo tradicional. Muchos de los consumidores perciben que si bien Software como Servicio puede ser económico inicialmente, pero no tanto en el largo plazo. Forrester piensa que esta afirmación por parte de los consumidores es apresurada y no tiene en cuenta factores como costos de mantenimiento, personal y otros beneficios como mejoras de funcionalidad incremental [Forrester Research, 2008].
Preocupaciones sobre la seguridad desde seguridad física hasta backup y roles y permisos. Entre el 40% y el 50% de los encuestados por Forrester citan temas de seguridad. Desde temas específicos como el riesgo de que los usuarios manejen roles y permisos de la aplicación a cosas menos específicas que el consumidor simplemente siente ("nos preocupa la seguridad pero no sabemos exactamente qué")
Figura 11 – Barreras para la adopción de Software como Servicio [Forrester Research, 2008] Por parte de los proveedores las barreras para la adopción son:
Gastos altos en ventas. El modelo de Software como Servicio promete un ciclo de ventas más rápido y fácil por el bajo riesgo que implica para el comprador pagar un bajo costo inicial en comparación con la venta de software tradicional. Sin embargo, a los proveedores de Software como Servicio les está costando mucho vender y alcanzar buenos márgenes. Por ejemplo Salesforce.com declaró en la conferencia de resultados financieros del segundo trimestre de 2008 [Seeking Alpha, 2008] tener ingresos por u$s 263 millones y un gasto en ventas y marketing de $130 millones. O sea un 50% de los ingresos. Por otro lado, captaron 4.100 nuevos clientes, eso significa que obtener cada cliente le cuesta a salesforce $32.000. Es un precio alto en comparación con el margen que deja en el corto plazo. La apuesta es que su marca siga siendo más fuerte, atraigan más clientes con menos esfuerzo y retengan los que ya tienen. Este mismo problema lo tienen la mayoría de las empresas que se basan exclusivamente en el modelo de Software como Servicio [Lacy, 2008].
Definición del Problema
Existe una demanda que se evidencia mediante los estudios de mercado citados en la sección 5.4 Adopción y Difusión y a medida que el modelo muestre adopción en la industria y los desafíos no superen las ventajas mencionadas, la demanda debería seguir creciendo. Tanto los productores de software buscando crear una solución Software como Servicio en el corto, mediano o largo plazo, como las compañías que quieran construir su propia plataforma basada en este modelo se enfrentarán con los desafíos que este modelo introduce y en poco tiempo, sino lo están haciendo hoy en día, se plantearán:
¿Cómo se construye software ofrecido como servicio? Esta es la pregunta que trata de responder esta tesis y está enfocada a los productores de software que quieren afrontar un proyecto de estas características y a los consumidores que deseen tener un panorama más acabado de los desafíos que esto implica.
Página siguiente  |