Software como servicio – SaaS

Todo lo relacionado con Saas, Paas, Cloud Computing…..

Archive for the ‘Estrategia’ Category

Microsoft Exchange y Sharepoint entran en producción

leave a comment »

En el dia de hoy Microsoft ha anunciado que los servicios online Exchange Online y Sharepoint Online han salido de la Beta y ya es posible disfrutar de estos dos productos, junto con Live meeting y Comunication Online, por un precio de 15$ al mes por usuario. Además es posible probar sus servicios durante un mes sin coste alguno.

La verdad es que no han tardado mucho en liberar el producto porque fué en Julio de este año cuando anunciaban la apertura de la beta y adelantaban los precios de los online services que como podemos ver sus precios no han variado desde aquel anuncio.

El acuerdo del nivel de servicio para las suit de productos online en lo que se refiere al pago por incumplimiento del acuerdo se puede ver en la tabla de abajo y al menos es capaz de devolver el 100% en créditos (=esto es lo mismo que cuando te dan un vale en un tienda y solo lo puedes canjear en la misma tienda), cosa que Amazon ni siquiera se plantea.

    i.     Uptime Service Levels

Monthly Uptime Percentage

Service Credit

 < 99.9%

25%

 < 99%

50%

< 95%

100%

El posicionamiento que quieren hacer del conjunto de productos es tan ambicioso como en muchos de sus productos: apuntar  a cualquier tamaño de empresa aunque bajo mi punto de vista productos como comunication online y Sharepoint solo los veo para empresas de al menos tamaño medio.

Esta claro que Microsoft ve en la nube una nueva fuente de ingresos y no quiere dejar escapar esta nueva tendencia del cloud computing.  La prueba está en que en un breve espacio de tiempo han anunciado SQL Data Service,  la plataforma como servicio Windows Azure, el nuevo Office que estará en la nube y estos servicios. Atrás quedan los días donde en Microsoft defendían el software + servicios en una estrategía más de comunicación y reorientación de sus mismos productos que de seguir la arquitectura de desarrollo (multitenancy) y modelo de negocio del software as a service. Veremos cual es el siguiente paso de este gigante.

¿Y si me quedo sin internet?

with 2 comments

Antes de ayer , a través de los comentarios me hicieron una pregunta que cuando empecé a contestar pensé que mucha gente se hará la misma pregunta y vi que el tema tenía tanta “chicha” como escribir un post. Pego el comentario:

En primer lugar, enhorabuena por el blog me parece super interesante. Trabajo en una multinacional de Software con un programa de contabilidad muy conocido y usado por las pymes españolas. Mi opinión es, que realmente el modelo SaaS es muy interesante y es más, hemos conseguido que lo comprendan (hace unos años era impensable), realmente la pyme siente desconfianza por las comunicaciones. El otro día me comentaba un cliente lo siguiente: “me parece muy bien lo que me has explicado refiriéndose al modelo SaaS, pero si dices que se basa en nternet tengo dudas porque se me puede paralizar mi negocio y me contaba como Telefónica le dejó una semana sin Internet”.

Ante esto mi pregunta es, ¿Cómo lo véis?¿Creéis que las comunicaciones actuales pueden ser un obstáculo al modelo SaaS?

Antetodo tengo que agradecer a Aurea sus halagadoras palabras.

A la pregunta de Aurea, mi respuesta es que sin duda , la perdida de conexión a través de internet y por tanto la indisponibilidad de la aplicación, es una de las barreras de entrada al saas junto con el de la seguridad y privacidad. No olvidemos que a parte de perder el servicio de internet, el proveedor del saas puede tambien tener problemas en su infraestructura pero tampoco hay que olvidar que en la soluciónes tradicionales, nuestra infraestructura tambien puede darnos disgustos, con tiempos de respuesta y soluciones peores en comparación con los proveedores externos.

En el caso que nos plantea Aurea de su cliente, la mejor forma de resolver sus dudas es ayudarle a descubrir las posibles soluciones que existen ante la perdida del servicio de internet, y valorar si sigue siendo interesante el saas o por el contrario es preferible la aplicación tradicional.

Como cliente, lo primero que haría sería valorar el impacto que mi negocio o  mi gestión sufriría si pierdo alguna de la aplicaciones y las probabilidades de que ocurra. Preguntas como: ¿No puedo seguir con la operativa? ¿No puedo continuar con la tareas de mantenimiento o gestión (contabilidad, nóminas,etc.)? ¿Durante cuanto tiempo puedo estar sin la aplicación? ¿Qué perdida ecónomica me puede suponer? ¿Como son de importantes los datos para el funcionamiento de mi negocio?, etc.

Lo segundo sería ver qué posibles soluciones tenemos tanto por el lado del proveedor y por el lado del cliente:

  1. Podemos elegir una aplicación utilice Google Gears o otro tipo de herramienta para que el cliente pueda trabajar mientras no tiene conexión. Por ejemplo, Zoho Writer y Zoho Mail utiliza Google Gears y permite utilizar la aplicación aunque no tengas conexión. De momento en el mercado no hay muchas pero seguro que aparecerán más.
  2. Acceso a través de RTB o RDSI. Hasta no hace mucho utilizabamos el modem para conectarnos a internet, asi que una solución sería que el cliente contrate una linea RTB o RDSI  que en caso de perdida de ADSL permita su conexión a internet y por tanto a la aplicación. Si tenemos que la perdida de internet puede ser debido a problema de tu proveedor de comunicaciones convendría que la linea se contrate a otro proveedor. Al hilo de esto, no conozco proveedor de saas que permita acceso a la aplicación a través de RTB o RDSI (cabeceras de 8 ó 10 lineas) y puede que resulte interesante para determinas situaciones de perdida puntual de ADSL.
  3. Instalar otra linea de Internet con otro proveedor de ADSL pudiendo ser de menos capacidad y por tanto más barata.
  4. Comprar un acceso 3G con conexión al PC a través de USB y pago por consumo.

En tercer lugar para cada escenario encontrado en el primer punto, aplicaría una solución u otra en función de la criticidad de las aplicaciones y datos, los riesgos potenciales y tiempo máximo de indisponibilidad.

Y el cuarto y más importante,¿saas si o saas no?

Por ejemplo, pongamos un escenario donde para una gestoría con mucha actividad tiene una aplicación de contabilidad que se ha identificado como crítica, donde como mucho tenemos 2h como máximo de inactividad, donde las probabilidades de quedarnos sin ADSL son moderadamente posibles y finalmente el acceso a la aplicación debe ser rápido sin perdidas de rendimiento. Tenemos dos posibles soluciones: nueva linea ADSL y el acceso 3G , pero sabemos que la cobertura 3G en nuestra empresa no es la ideal y que hemos decidido poner otra linea ADSL con otro proveedor de comunicaciones.

Además ya contamos con 2 PCs para dos 2 usuarios que deben acceder a la aplicación sin que sea necesario ,en caso de emergencia,  que operen a la vez. Esto es lo que nos salé cuando comparamos uno y otro modelo (las cantidades son aproximadas pero pueden ser perfectamente válidas):

  In-House Software SaaS
Inversión Inicial Lo normal es que deberíamos comprar un servidor para localizar nuestra aplicación y datos y que ambos  PC´s accedan y almacenen en el mismo sitio. Coste linfraestructura(PC+red): 1.500€ – Coste aplicación: 400€ Nueva linea ADSL 
Gastos de mantenimiento Coste mes nueva infraestructura:30€ – Coste mes aplicación:50€ Coste: 30€/mensuales – Coste aplicación por 2 usuarios/mes: 80€
Riesgo de adopción Alto riesgo por la inversión Bajo, no tienes inversión
Acceso a al aplicacion y datos Desde la empresa Desde cualquier punto, incluso tu casa.
La carga operacional recae sobre La infraestructura del cliente Proveedor de la Solución Saas
Tiempo de desarrollo o configuración Alto Medio
Facilidad de migración de las versiones Requiere una planificación Corre a cargo del proveedor del Saas
Disponibilidad de la aplicación Total Total
Retorno de la Inversión Lento debido a la inversion inicial Rápido y más predecible
Posbilidad de errores durante la implantación Alta Ninguna, accedes a traves del navegador
Capacidad añadir o eliminar usuarios Dependiendo de la licencia Si, rápidamente.
Seguridad de los datos(Backup, Accesibilidad,etc) A cargo del cliente A cargo del proveedor del Saas
Facilidad de despliegue de la aplicación a los usuarios Depende del tipo de aplicación Tan rápido como conectarse al proveedor del Saas
Precio mes 80€ mensuales 110€ mensuales

 y ahora sopesando inversión, ventajas y desventajas, y precio mensual, solo hay que contestar a la pregunta . ¿saas si o saas no?

Written by jcmmartin

noviembre 15, 2008 at 10:46 am

¿Es realmente interesante el saas para la PYME?

with 6 comments

saaspyme1Ya sabemos las ventajas y desventajas que el software as a service nos ofrece. En general el saas nos reporta ahorro de la inversión en infraestructura porque no necesitas instalar el software en servidores dedicados, ahorro en mantenimiento de la instalación y de las versiones, un precio bajo y relacionado con quien y/o cuanto usas la aplicación, backups incluidos en el precio, soporte y arreglo rápido de los bugs que puedan aparecer en la aplicación y podriamos añadir algunos más pero estos son los  que más destacan y para lo que quiero exponer es suficiente.

Todo esto esta muy bien pero si de lo que hablamos es de micropymes podría cambiar la cosa. El otro día hablando con mi hermana, ex-empresaria y ahora contable de una asesoría,  me decía: “a mi todo esto me parece muy bien pero para nosotros esto no es interesante”. Yo firme defensor del saas y del matrimonio pyme-saas, muy en mi sitio y casi ofendido le dije que me lo explicara y me dijo:

Pues no, porque yo no tengo infraestructura. No tengo el software en ningún servidor, con lo cual no me ahorro en infraestructura y su mantenimiento. Hacemos backup a diario en CDs de lo que realmente nos interesa porque una empresa les asesoró cuando se hizo la instalación de los PC´s. El software que yo utilizo, osea,  un programa contable, lo tuvimos que renovar este año por el cambio de legislación pero llevaban años con el mismo software y no necesitaban más. Es un software comercial que nos han recomendado con un coste de 400€ y tu me hablas de 10  a 20 euros por mes en el mejor de los casos. ¿Que me soluciona el saas ese a mi?

Evidentemente es un ejemplo muy concreto pero si es cierto que hay cierto tipo de software que no renuevas anualmente, que es estable y por tanto merece la pena hacer cálculos y sopesar el precio del software in-house y el precio saas.

No obstante a mi modo de ver hay tres cosas con las que no contó mi hermana. La primera de ellas es que no es ella la que tenia que desembolsar el dinero y que no solo tenían una aplicación para la contabilidad; tambien tienen aplicaciones para nóminas, facturación, gestión de cobros, etc  y todos estos productos pueden sumar un cantidad importante que a lo mejor el empresario no puede hacer frente y le es más cómodo “pagarlo a plazos” aprovechando las ventajas adicionales del saas.

La segunda es que quizás y solo quizás, al igual que lees el correo de Gmail, Yahoo o Terra desde cualquier punto del planeta, si fueras empresario, te surgiera alguna duda sobre algo de tu empresa y tuvieras la oportunidad de conectarte a internet y consultarlo (sin tener que instalarte nada en tu PC), a lo mejor esa noche duermes mejor. Por si acaso, alguien se lo pregunta. ¿Quien mejor que un profesional de la seguridad, almacenamiento y disponibilidad de la información para que guarde y vele por tus datos? Es un cambio de mentalidad y visión dificil de llevar pero ¿No me digas que el dinero lo guardas debajo del colchón? 😉 Bueno Stallman seguro que utiliza el método del colchón pero el resto de los humanos tiramos del banco.

La tercera y la que me parece más importante son:  los fallos. A mi hermana la instalación del software en su PC le fue bien pero ¿cuantas veces nos hemos encontrado con problemas en la instalación del software por tener otras instalaciones en el mismo PC? Además hay que tener en cuenta los fallos en el software que en general te los arreglan durante el primer año pero después o pagas mantenimiento o adiós muy buenas. Y otra más gorda que no te acuerdas de ella hasta que te pasa: ¿Tienes la completa seguridad de que puedes recuperar tus datos si tu disco duro se va al carajo?

En resumen, que no todo es oro lo que reluce ni en el saas , ni en el  in-house y como en todo hay que estudiarlo,  ver los pros y los contras de cada situación y empresa para poder tomar la mejor decisión que rentabilice nuestra inversión.

Written by jcmmartin

noviembre 7, 2008 at 12:03 am

Los 10 errores más comunes de una startup de saas

with 9 comments

El otro día comentaba Enrique Dans en uno de sus post que Zoho es el más listo de la clase porque entre motivos, ha empezado a utilizar Google Gears antes que el propio google. La verdad es que Zoho no ha parado de poner software online en los 3 años que llevan de vida y lo hacen realmente bien pero para mí, dentro del mundo “as-a-service” , el más listo de la clase siempre ha sido Salesforce, que con su CRM online ha conseguido ser una referencia en este mundo y ahora con Force quieren ser tambien los líderes en el mundo de las platform as a service.

Para promocionar Force están lanzando una campaña de comunicación y ayuda para que aquel emprendedor que quiera focalizar su esfuerzo en el desarrollo del software as a service, tenga toda clase de información a traves de white papers con consejos para su creación y seminarios web online . Por eso digo que son listos y los primeros de la clase porque como comentaba hace algún tiempo estos tios en Force no cobrán al desarrollador, hacen caja con la base instalada de clientes que utiliza su CRM y que ahora pagará si quiere utilizar una de las aplicaciones que estos nuevos proveedores de saas desplegaran en su plataforma.  De ahí que se dediquen a atraer proveedores de saas con sus aplicaciones para hacer un “poco” mas de caja. 

Hace unos dias publiqué un resumen en español de un informe de Salesforce que hablaba sobre las 7 claves a tener en cuenta en la creación de una saas, y ahora dejo otro resumen de este paper sobre los 10 errores más comunes que suelen cometer cuando lanzas una empresa de saas:


Recuerda que el modelo de negocio de saas es diferente

Error 1.- Ejecutar tus procedimientos operativos como si fueras una compañia de software tradicional. Tus beneficios dependen de ingresos paulatinos y no de grandes ventas, por eso debes tener cuidado con tus gastos fijos y monitorizar la renovación de tus suscripciones e indicadores de futuros ingresos.

Error 2.- Gastar demasiado en marketing y fuerza de ventas. El marketing tradicional y en concreto la publicidad puede resultar muy costosa y hay proveedores de saas que han encontrado fórmulas de marketing más economicas e igual de efectivas.

Error 3.- No poner interés en que el cliente use producto. Si conoces el uso de tu producto, el numero de clics que reciben tus páginas, aquellas que no se utilizan entonces intenta sacar provecho de está información para dar al cliente lo que quiere.


Evita errores de marketing comunes

Error 4.- Conformarte con la mentalidad “construido-ya vendrán”. Necesitas tener una estrategia promocional agresiva que identifique a tu target y los diferentes canales de acceso.

Error 5.- Esperar a que tu cliente tenga éxito. Haz lo posible para que tu cliente utilize y saque partido de la aplicación y que obtenga el beneficio que esperaba. Manuales, videos, soporte online, etc…

Error 6.- Subestimar el poder de la referencias de clientes y de los evangelistas. Los testimonios de clientes y comentarios de los evangelistas hace más estable y confiable tu producto.

Error 7.- No poner interés en las comunidades de usuarios. Los foros de usuarios ayudan al clientes a manejar mejor la herramienta y sirven de soporte de la misma, evitando que el cliente necesite el nivel de soporte básico.  Encuentra a los usuarios evangelista más activos, incentivalos y escuchalos.


No tengas en cuenta como se hacen las cosas en el desarrollo tradicional

Error 8.- Utilizar metodologias tradicionales para la entrega de saas. En el desarrollo tradicional hasta que no tengas un número de cambios funcionales importante no empaquetas para en lanzamiento de una nueva versión. En saas no es necesario hacerlo e incluso puede ser contraproducente hacerlo así porque no creas expectación , dinamismo en la aplicación y parece que no escuchas las peticiones de tus clientes.

Error 9.- Invertir en infraestructura más de lo necesario. Esto es directamente “promocional” a Force, pero es completamente cierto que es una ventaja no invertir en Iaas ( infraestructure as a service) cuando hay gente que lo hace bien y es su negocio.

Error 10.- Que te pillen sin un API. Es necesario que el cliente no sienta que sus datos están aislados de su sistema y que tenga la “oportunidad” de sacar sus datos y llevarlos a otro proveedor de saas.

Siete claves para un proyecto saas de éxito

with 7 comments

Esta mañana revisando el blog de Force me he encontrado con esta entrada que me ha encandilado porque en sus referencias aparecía este whitepaper que explica qué debe tener en cuenta una empresa de saas de reciente creación para que concluya y mantega su éxito. No estoy seguro de cuando se liberó el pdf pero es igual de interesante por los puntos que destaca y porque aparecen unas cuantas referencias de empresas (con declaraciones de su CEO) acerca de cómo y porqué les fué y les va viento en popa en este nuevo mundo. 

Una de la cosas que más me ha llamado la atención es que el software tradicional y el software as a service se gestionan de diferente manera (desde su captación hasta su entrega al cliente)  y muchas de la prácticas y procedimientos comumemente aceptados en la creación del software in-house no tienen sentido en el saas. Esta la típica chorrada que cuando te la dicen, la afirmas como obvia pero que en tu día a día no dejas de hacerla, por eso me gusta destacarla.  

Resumo las siete claves para que un proyecto Saas tenga éxito: 

  1. Busca líderes del proyecto responsables. El proyecto debe tener un líder que entienda la solución saas y que acepte las  diferencias entre la creación de software tradicional y el modelo saas. Además debe intentar encontrar las métricas correctas para evaluar el estado del proyecto (tasa de adopción, utilización del sistema, desgaste de la solución) , asi como de su comunicación dentro de la compañia y los responsables de cada métrica.
  2. Haz aplicaciones que tus usuarios necesiten. Debes intentar deleitar a tus usuarios para que vuelva a utilizar tu aplicación con nuevas actualizaciones, interfaces intuitivos, upgrades automáticos que no fastidien sus personalizaciones. Además de tener la posibilidad de escuchar a tus usuarios(chat,tablon de sugerencias), de informales sobre actualizaciones y futuras mejoras, de saber que es lo que más utilizan y que no, etc. En definitiva crear expectación, darles lo que quieren y disponibilidad.
  3. Genera demanda las 24h del día. Apoyándote en la información que tienes de tus usuarios intenta generar demanda con actuaciones como accesos free a una parte de la aplicación, eventos, seminarios, videos, promociones,etc..
  4. Vendes servicio, no producto. Vendes un servicio completo, esto es entrega de producto, soporte y mantenimiento. Esto impacta en tu equipo de ventas y en tu equipo de desarrollo porque a diferencia del software tradicional, la fijacion de precio, el cumplimiento del mismo, la fidelidad del cliente, el mantenimiento de la aplicacion, el acuerdo del nivel de servicio(SLA), infraestructura para el cumplimiento del SLA,etc..  se tiene diferente tratamiento. No es lo mismo dejar un proveedor intermediario que mantega el código o que el propio cliente lo mantenga a que recaiga sobre el proveedor Saas. 
  5. Haz una religión del éxito de tu cliente. Ganar-ganar, si tu cliente gana tu ganas. Intenta destacar éxitos de tus clientes para obtener la atención de futuros clientes, realiza encuentas de satisfación y resuelve las quejas cuanto antes para fidelizar clientes, intenta crear grupos de clientes exitosos para enseñar a nuevos clientes, etc.. En definitiva el cliente debe renover suscripción y debes intentar hacer lo que sea para que vuelva a probar tu aplicación. 
  6. Desarrolla buenos procesos financieros. Debido a que los ingresos recibidos en el saas son incrementales y dependientes de las renovaciones, el tratamiento de la finanzas de la empresa saas es uno de los factores críticos a tener en cuenta.  Hay que tener especial  cuidado con el cash-flow, con los gastos fijos iniciales debido a la infraestructura, intentar poner medio de cobro automáticos, aprovechar el conocimiento del crecimiento de uso de aplicacion para prever futuras inversiones,etc.
  7. Encuentra tu sitio en el Universo “mashup. Busca alianzas o utiliza webs de “remezcla” que potencien el uso de tu aplicación. Esto es un oda a “Force” como plataforma de aplicaciones (Paas– platform as a service) pero es una opción más a tener en cuenta para que tus potenciales clientes conozcan tu saas. 
El paper son 16 hojas y esto es un breve resumen, y aunque es un poco pesada la lectura en inglés la aconsejo porque me parece realmente interesante. 

¿Saas para aplicaciones críticas?

with one comment

Cierto es que el software as a service tiene unas cuantas ventajas y otras desventajas pero cuando nos plateamos la posibilidad que nuestros datos y la lógica de nuestro negocio quede fuera de las cuatro paredes de la empresa, la ventajas y desventajas van cogiendo y disminuyendo peso para justificar las decisiones. Si además los datos que manejará la aplicación saas, son datos críticos para el funcionamiento de nuestra empresa, la decisión hacia la adopción del Saas aun se complica más, y si encima la disponibilidad de estos datos debe ser 24×7 (24h, 7 dias a la semana) la adopción del Saas practicamente desaparece.

Para intentar paliar esto y dar confianza a sus clientes, muchos proveedores de Saas que ofrecen acuerdos de nivel de servicio (SLA) de 24X7, como por ejemplo Salesforce, con un porcentaje de perdida de servicio realmente pequeño y que podria servirnos para cubrir nuestras necesidades de disponibilidad, pero sabemos que este tipo de consumo de software se realiza a través de internet y nos obliga a que el proveedor de comunicaciones nos ofrezca un nivel de servicio parecido que el de la aplicación Saas. Esto puede ser realmente costoso disminuyendo el peso de uno de los principales factores de compra: la reducción de costes e inversión.

Por otro lado, la edad de la empresa tambien es importante e influirá a la hora de tomar esa decisión. No es lo mismo que la decisión se esté formando desde una start-up donde aún no tenga su sistema de información asentado  que de una empresa consolidada y con años en su mercado  que tenga su sistema de información en marcha y en casa.

Otro factor importante que puede influir en la decisión de compra es la cultura de la empresa, esto es, una empresa conservadora con dificultades históricas en la adopción de tecnología será mucha más reticente que la empresas dinámicas, emprendedoras y que no les importa el cambio. Este post de Enrique Dans me ayuda a explicar el concepto .

Y por supuesto la reducción de costes e inversiones en empresas con problemas financieros puede ser determinante pero tambien lo es para para aplicaciones no críticas.

En mi opinión de todo lo expuesto lo que realmente frenará la entrada de saas en aplicaciones críticas será Internet y quizás sea cuestión de tiempo, de fiabilidad y de confianza , como la luz y el agua de los que nadie duda de su disponibilidad.

 

Written by jcmmartin

mayo 27, 2008 at 10:32 pm

¿Cuales son los requisitos mínimos del Saas?

with 2 comments

Desde el punto del cliente que va a adquirir los servicios de una aplicación ofrecida como servicio, existen una serie de requisitos mínimos necesarios que una Saas debe ofrecer:

Rendimiento.- Una saas debe ofrecer un rendimiento mínimo y aceptable para que sea atractiva su adquisición. El problema aquí es definir mínimo y aceptable y aunque es un concepto subjetivo puede ser medible en tiempos de respuesta en el acceso a los datos, de ejecución los procesos de negocio, de comunicación a la propia aplicación ( delay producido por el alojamiento geográfico de esta), etc….

Acuerdo de Nivel de Servicio ( en inglés Service Level Agreement) .- El ISV de la aplicación Saas debe proveerte de varios niveles de servicio al que los cliente pueda adherirse. Habrá clientes que necesiten su aplicación disponible 8×5 (5 dias a la semana, 8 h) y habrá que clientes que necesiten 24 X 7. El ISV deberá instalar en sus sistemas los mecanismos necesarios para poder ofrecer este tipo de acuerdos, esto es, backup,  cluster de alta disponibilidad de datos y aplicación, etc…..

Privacidad en las comunicaciones.- Debido a la importancia de los datos que puedan albergar las aplicaciones en necesario que la comunicacion que se realiza a través de Internet sea segura, esto es, la comunicación debe realizarse a través de https u otra forma de comunicación que asegure la privacidad de las comunicaciones.

Privacidad de los datos.- De igual forma el ISV debe asegurar que los datos esten seguros y accesibles única y exclusivamente por el dueño del dato. Esto debe ser especialmente perseguido en la aplicaciones multitenancy ( nivel 3 y 4 de maduración) que explique en este post.

Monitorización de la aplicación.- El cliente debe saber de alguna forma que es lo que ocurre en su aplicación, por ejemplo: quién accede, a qué procesos, a qué datos,etc. Esto es obligado cuando el pago por el uso de la aplicación se realiza a través de conceptos como horas de utilización de la aplicacion, consumo de espacio de disco, o cualquier otra forma que sea variable.

Acceso de a los datos.- El resto de la aplicaciones de la organización deben acceder a través de APIs o de Web Services , a los datos y lógica de negocio que se utilizan y genera por el uso de la saas, sobretodo, en clientes que tengan adoptado la arquitectura SOA en su sistema de información.

Written by jcmmartin

mayo 18, 2008 at 10:29 am

Noticias como servicio – 5 al 11 Mayo

with one comment

Estas son las noticias que más me han llamado la atención en esta última semana:

¿Cual es el modelo de saas óptimo?

with 7 comments

Cuando nos enfrentamos a elegir qué aplicación saas queremos que cubra cierta funcionalidad para nuestra empresa o area funcional, debemos saber que es lo que nos ofrece el proveedor desde diferentes puntos de vista. Por ejemplo, no es lo mismo que el software te lo ofrezca a tí solo, que lo compartas con otros clientes y tampoco es lo mismo que el recurso que compartes sea el código de la aplicación que la base de datos donde lo almacenas.

Para decidir que es lo que más nos interesa desde el punto de cliente, antes veremos que es lo que actualmente nos podemos encontrar en el mercado tomando como referencia lo que Microsoft definió y llamó el modelo de madurez de saas. Este gráfico nos ayudará a entender los niveles de maduración que a continuación se describen (puntualización: cuando se habla de instancia se refiere a lógica de negocio y datos, no solo a código):

  • El primer nivel de madurez es similar al tradicional Aplicación Service Provider (ASP), modelo de entrega de software, que se remonta a la década de 1990. En este nivel, cada cliente tiene su propia versión personalizada de la aplicación , y cuenta con su propia instancia de la aplicación en los servidores del proveedor de saas.
  • En el segundo nivel de madurez, el proveedor del software ofrece una instancia para cada cliente (o inquilino) pero a diferencia del primer nivel donde cada cliente tiene su propia versión, en este nivel, todos los instancias utilizan la misma versión de la aplicación, y el proveedor cumple con las necesidades de los clientes mediante las opciones de configuración.
  • En el tercer nivel de madurez, el proveedor a traves de una única instancia da servicio a todos los clientes, ofreciendo la posibilidad de cada uno pueda configurar la metaestructura de la aplicación para personalizarla . Las políticas de autorización y seguridad permiten que cada cliente mantenga sus datos separados de los de otros clientes y, desde el punto de vista del usuario , no hay indicios de que la instancia esté siendo compartida entre varios clientes. Como varios clientes comparten una instancia, los datos de cada cliente son lógicamente separados de la de otros clientes.
  • En el cuarto y último nivel de madurez, el proveedor da servicio a varios clientes a traves de varias instancias de nivel 3 balanceando la carga ( clientes conectados a cada instancia) de cada instancia . Cada instancia puede dar servicio a varios clientes desde máquinas distintas ofreciendo este nivel un alto grado de escalabilidad , ya que el número de servidores pueden ser aumentados o disminuidos, según sea necesario para satisfacer la demanda, sin necesidad de rediseño de la aplicación. Salesforce ofrece un nivel 4 de madurez con posibilidad de configurar tus propias tablas compartiendo la misma BBDD.

Como se puede ver a medida que aumenta el nivel de madurez se obtiene un mayor aprovechamiento de las economías de escala provinientes de la reducción en cada nivel de los recursos necesarios que componen la solución y por tanto del menor mantenimiento.

Desde el punto de vista del proveedor el nivel de madurez elegido para su aplicación Saas dependerá del compromiso entre el coste de la solución y el beneficio a obtener a corto,medio y largo plazo. Tambien dependerá de los productos propietarios del proveedor que rodean a la solución saas, por ejemplo si el proveedor dispone de un servidor de aplicaciones propietario, rapido, estable y consume pocos recursos de la máquina, es posible que le merezca la pena quedarse en el primer o segundo nivel de madurez y ofrecer un servidor de aplicaciones para cada instancia o quizás no porque el mantenimiento de tener varios servidores de aplicaciones es mayor.

Desde el punto de vista del cliente, además de saber cual es el nivel de madurez que ofrece el proveedor ( hay que tener en cuenta que en todo momento hemos hablado a nivel de instancia) me parece importante que además informe de las posibilidades que tengo en cuanto a infraestructura, por ejemplo:

  • ¿ Puedo tener mi aplicación en una máquina en exclusividad?
  • ¿Puedo tener mi aplicación en un servidor de aplicaciones en exclusividad?
  • ¿Comparto el servidor de aplicaciones con varias instancias por cada cliente?
  • ¿Comparto la BBDD de Datos con otros clientes?
  • Si me ofrece un nivel 3 de madurez y comparto la BBDD. ¿A que nivel se comparte? ¿a nivel de tablas o nivel de esquema de usuario?

Por tanto, vistos los niveles de madurez y la posibles combinaciones de infraestructura que nos pueden ofrecer, estos serán los factores que intervendrán a la hora de adoptar la solución:

  • Seguridad de los datos, habrá clientes que prefieran un nivel de madurez bajo para que sus instancias ( logica y datos) esten separadas del resto de instancias correspondientes a los otros clientes por miedo que sus datos puedan ser vistos por otros clientes.
  • Rendimiento, de igual forma habrá clientes que prefieran que sus instancias esten separadas para que el rendimiento no sea dependiente del numero de clientes que se conecten a la instancia, incluso preferiran que el servidor de aplicaciones sea diferente.
  • Escalabilidad, el potencial crecimiento de uso de la aplicación puede tambien ser determinante y los niveles bajos ofrecen soluciones menos optimas para el proveedor y por tanto más caras que los altos.
  • Nivel de servicio (disponibilidad de la aplicación), por ejemplo un nivel 4 de madurez nos garantiza un nivel cercano al 100% de servicio de la aplicación y posiblemente un coste reducido por el uso del mismo.
  • Coste del saas, a priori un nivel bajo de saas debería ser más caro que un nivel alto de saas y por tanto esto influirá en la decisión del cliente. Digo que debería porque un saas con un nivel de madurez alto requiere mayor diseño y desarrollo que uno bajo y por tanto requerirá mayor inversión ( aunque tambien se aprovechan de las economías de escala) y esto puede revertir en el precio al cliente final. Este dato es dificil de obtener y costoso de comparar.

Resumiendo, debemos tener en cuenta tanto los niveles de madurez como la infraestructura donde corren estos niveles y elegir qué solución es la que más nos adecuada que engancha con nuestra cultura de empresa, que cubrá nuestra necesidades de funcionalidad y que cumpla con nuestros requerimientos de seguridad , servicio de aplicación y rendimiento.

Written by jcmmartin

mayo 11, 2008 at 5:31 pm

¿Cuales son las diferencias entre ASP y Saas?

with 5 comments

Desde hace unos días me rondaba la cabeza escribir un post sobre las diferencias entre ASP y Saas y ayer finalmente decidí que lo tenía que hacer a consecuencia de un mail que recibí de uno de los lectores de este humilde blog. En el mail me hacía una serie de preguntas utilizando el acrónimo asp y otras utilizando el acrónimo saas, y no llegué a identificar si era un problema de utilización del acrónimo correcto o es que de verdad se estaban confundiendo los significados.

Si buscamos información del termino ASP y Saas e incluso si buscamos “diferencias entre ASP y Saas” aparecen muchas entradas que intentan explicar los terminos pero la mayoría de las comparaciones confunden el termino ASP con Hosting y a partir de ahí la comparación con Saas no sirve para nada. Me gustaría aclarar primero qué es ASP y qué es Hosting apoyándome en estas definiciones que encontré:

  • En modo ASP se paga una cuota periódica por alquilar la plataforma. Dentro de esta única cuota estarían incluidas las licencias, hosting, mantenimiento, etc.
  • En régimen de Hosting pagas licencias y/o el proyecto y puedes alojarlo en servidores de tu propiedad o quizá del proveedor.

Creo que queda claro que con ASP se paga por uso y con Hosting pagas licencias de los productos que usen y las máquinas pueden ser tuyas o alquiladas pero se encuentran en casa del proveedor. Aclarados estos conceptos intentemos aclarar las diferencias entre ASP y Saas.

ASP significa Application Service Provider ( en español Proveedor de servicios de aplicaciones ) y como explica la wikipedia en su primer párrafo, proporciona servicios de software. El resto ( lo pego para no tener que acudir) dice lo siguiente:

“Entre los factores que caracterizan a un PSA se destacan la amplia difusión del uso de Internet, la capacidad de acelerar el despliegue y puesta en marcha de aplicaciones y la posibilidad de transferir servicios y operaciones a terceros. La barrera principal para un PSA radica en convencer a sus clientes de que su información en manos de un tercero permanece segura. Por otro lado, son dueños y operadores del hadware y el software y rentan a los clientes el uso de aplicaciones de la computadora.”

Veamos ahora a la definición que la wiki hace de Saas:

“Software como Servicio (del inglés: Software as a Service, SaaS) es un modelo de distribución de software en donde la compañía de IT provee el servicio de mantenimiento, operación diaria, y soporte del software usado por el cliente. En otras palabras es tener la información, el procesamiento, los insumos y los resultados de la lógica de negocio del software. En palabras simples: El cliente tiene el sistema hospedado en la compañía de IT. Es software donde el acceso es vía Internet. No necesariamente se da por medio de navegadores Web, la lógica de negocio reside en la localidad central del proveedor.”

Y la verdad, esta escrito con distintas palabras pero hay muy pocas diferencias :

  • Se accede a través de Internet.
  • En un servicio de uso y de mantenimiento.
  • Se paga por uso, no por licencia.
  • Los datos y la lógica de negocio en casa del proveedor.
  • Las aplicaciones no necesariamente se ofrecen a través de navegadores y por tanto a veces será necesario instalar software en el cliente y otras no.

Y entonces ¿Cuales son la diferencias entre ASP y Saas?. Pues aunque no lo parezca si hay diferencias:

  • ASP es un alojador de software propietario de otros ISV. En el modelo Saas son los propios ISV( los creadores del software) los que ofrecen el hosting y el software en un solo paquete.
  • Muchas de las aplicaciones que corren o corrían en los ASP no están preparadas para dar acceso a través de internet. He visto acuerdos del 2002, 2003 de HP, SAP, etc, con ASP para ofrecer a través de internet las mismas aplicaciones que fueron diseñadas para correr in-house.
  • Estas mismas aplicaciones tampoco fueron diseñadas para dar servicio a múltiples clientes de distintas empresas, es más, se ejecuta una instancia por cada cliente del ASP. La mayoría aplicaciones como servicio (modelo saas) si están diseñadas para ofrecer la aplicación a varios clientes a través de una sola instancia (multitenancy)
  • Relacion con lo anterior, al proveer una instancia cobertura varios clientes a la vez es necesario que la aplicación tenga un alto nivel personalización para cada cliente.
  • Aunque hemos visto que no necesariamente las aplicaciones ofrecidas como servicio ( modelo saas) se consumen a través de un navegador y por tanto no requieren instalación en el cliente, en verdad la mayoría de ellas se consumen a través del navegador. De hecho no conozco ninguna Saas que no sea así. Las aplicaciones que corren en ASP pueden o no ejecutarse a través del navegador y por tanto requerían de una instalación adicional en el cliente ( un emulador de windows o de unix, el escritorio remoto, terminal server, citrix).
  • Relacionado con lo anterior, ASP puede ofrecerte distintas aplicaciones y de diferentes tipos dependiendo de los acuerdos que llegue con las compañías propietarias de software. Esto sin embargo es más complicado que se consiga en el modelo saas, normalmente el ISV te ofrece un solo software aunque tambien tenemos ejemplos coomo google apps o zoho que ofrecen más una.
  • Por ultimo, algo más que evidente es que en el modelo saas podemos disfrutar de un soporte directo, más personalizado, y sin intermediarios que puedan escurrir el bulto ante un problemas del software.

Espero que el post haya despejado más dudas que añadirlas y que en todo caso genere polémica suficiente para que lleguemos a aclarar los términos.

Written by jcmmartin

mayo 9, 2008 at 9:08 am

Publicado en Estrategia, Software como servicio

Tagged with , ,