Selección de aplicaciones SaaS. Fin del servicio

 

Continuando con la serie de Puntos clave para la selección de aplicaciones de negocio en modo SaaS, llegamos al relacionado con las condiciones de Salida o Finalización del Servicio, donde es obvio que deberemos asegurarnos de la facilidad y rapidez de salida en el caso en que haya problemas, y así no quedarte atrapado por tu proveedor. Este punto está bastante estudiado (vendor lock-in le llaman en la literatura especializada) y es una de los puntos que más se citan como impedimentos y reticencias a los modelos SaaS.

A mi parecer, se ha de tener en cuenta:

Continuar leyendo

Selección de aplicaciones SaaS. Evolución

 

Dentro de la serie Selección de aplicaciones de negocio SaaS. Puntos clave no podían faltar aquellos relativos a asegurar la evolución adecuada del servicio que esperamos recibir una vez puesto en marcha dicho servicio, o dicho de otra forma, de la elasticidad de la aplicación para adaptarse a las necesidades cambiantes que seguro va a tener nuestra empresa.

Por eso deberemos pedirle al proveedor de la aplicación información sobre:

Continuar leyendo

Selección de aplicaciones SaaS. Inicio del servicio

Continuando con la serie de qué puntos clave tenemos que considerar en la selección de una aplicación de negocio en modo SaaS, en esta entrada comentaremos aquellos puntos que hacen relación a la puesta en marcha del servicio.

Uno de los atractivos de utilizar un modelo SaaS pasa por la premisa de que en general todo tiene que ser más rápido y sencillo. Es una hipótesis de partida porque de no ser así el modelo no es sostenible ni viable y debemos, por tanto, prestar atención a todos los elementos que nuestro proveedor pueda aportar en este sentido, … rapidez y sencillez en que:

Continuar leyendo

Selección de aplicaciones SaaS. Tecnología

Seguimos con la Serie de los puntos clave que se tienen que verificar cuando se busca una aplicación de negocio SaaS. Esta vez le toca el turno al aspecto más Techie. Espero que nadie se eche atrás 🙂

Como ya se ha comentado anteriormente, la tecnología ha desempeñado un importante papel en el desarrollo viable de los modelos SaaS por lo que, para asegurarnos que nuestro proveedor SaaS tiene un modelo de negocio sostenible,  es importante poder contrastar con él cosas como:

Continuar leyendo

Selección de aplicaciones SaaS. Multi-tenancy

 

Seguimos con la serie de Puntos clave para la selección de aplicaciones de negocio SaaS con el que creo más importante, confuso y complejo frecuentemente y el que considero que es crucial a la hora de decantarnos por un determinado proveedor de aplicaciones de negocio SaaS ya que de alguna manera abarca, o es consecuencia, del resto de puntos clave que se comentan en esta serie: el multi-tenancy.

En una primera aproximación se podría definir que una aplicación de gestión SaaS es Multi-tenancy si:

Continuar leyendo

Selección de aplicaciones SaaS.Puntos clave

 

Mover las aplicaciones de negocio (ERP, CRM, etc.) a la nube (en modo SaaS) es una tendencia en ascenso entre los responsables de las tecnologías de la información en las empresas (en este último informe que he leído, por ejemplo, lo explican muy bien).

No tengo cifras locales concretas (si alguien las tiene que comente), sólo mi experiencia directa hablando con colegas, clientes y proveedores, pero esta tendencia parece más tímida en nuestro entorno que en otros y es que por alguna razón aquí siempre somos más precavidos en lo de introducir cambios, por decirlo amablemente, o quizá no haya una oferta suficiente.

Aunque es comprensible que los responsables de llevar a cabo e impulsar este tipo de innovaciones en las empresas tengan muchas y serias dudas, dado el riesgo (no siempre mayor que continuar igual, todo sea dicho) que puede suponer un cambio estratégico de ese calibre en la gestión de la información de sus empresas.

Como estoy plenamente convencido de que es cuestión de poco tiempo que el modelo dominante de tener tu ERP, CRM etc. in house se quede obsoleto (*) y con el ánimo de contribuir, en la medida de mis modestas posibilidades, a romper, mediante información, transparencia y debate, esos miedos y dudas, me he decidido a escribir una serie de entradas sobre qué es lo que hay que saber antes de decidir mover las aplicaciones de negocio a un modelo SaaS.

La serie, que iré publicando paulatinamente en los próximos días, la he estructurado alrededor de los siguientes puntos clave:

  1. Multi-tenancy. Como condición necesaria para que el modelo sea sostenible.
  2. Tecnología. Consideraciones respecto de la arquitectura tecnológica de la aplicación SaaS.
  3. Inicio del Servicio. Qué hemos de tener en cuenta en relación a como se pone en marcha el servicio.
  4. Evolución del Servicio. Qué debemos gestionar para asegurar la adaptación de la aplicación SaaS a los requerimientos cambiantes de nuestra organización.
  5. Fin del servicio. Elementos importantes en el momento de finalizar la relación con el proveedor de la aplicación SaaS
  6. Integración. Consideraciones a la relación de la aplicación SaaS con otras aplicaciones
  7. Privacidad. Cómo cumplir la legislación vigente y proteger nuestros datos sensibles.
  8. Gestión del servicio. Gobierno de la relación con el proveedor y gestión de la calidad del servicio.
  9. Costes. Qué elementos de coste hemos de vigilar.

Cada uno de los temas se desarrollarán desde el punto de vista de una empresa que está considerando una estrategia SaaS para sus aplicaciones de negocio y que quiere validar las capacidades de potenciales proveedores. No obstante, me gustaría que esta serie fuera útil, no sólo para aquellos responsables de sistemas de información de esa hipotética empresa sino también también para que proveedores de aplicaciones y servicios comprueben que su oferta es competitiva y se ajusta a un modelo SaaS de verdad o True SaaS.

Para acabar esta primera entrada, los puntos cubiertos en la serie, por genéricos, deben considerarse como una guía de partida, una especie de check-list, nunca deberían ser sin más el único elemento para tomar una decisión. Si crees que necesitas una ayuda más adecuada a tus necesidades específicas no dudes en contactarme 🙂

El resto de la serie y otras entradas relacionadas: Selección de aplicaciones de negocio SaaS. Puntos clave

 

[ *] Sobre modelos obsoletos siempre me gusta citar a Nicholas Carr, uno de los primeros visionarios de lo que ahora se ha venido a llamar Cloud Computing,que explica en varios de sus libros y artículos como principios del siglo XX las empresas industriales tenían sus propios generadores eléctricos y pozos de agua in house y que al extenderse las redes de distribución de electricidad y agua se cambiaron a la Energía y Agua as a Service.  Modelo que ahora, salvo contadísimas excepciones, vemos como el único racional y sostenible.

 

Foto: Michael Heiss

 

Actualización 23/1/2012:

En la línea de que los modelos SaaS avanzan en su implantación, enlazo este post que recoge una serie de pronósticos de relevantes analistas.

 

Actualización 25/1/2012:

En la encuesta del 2012 que Gartner hace a  CIOs de todo el mundo, de las 10 prioridades tecnológicas, el Cloud Computing (SaaS, PaaS, IaaS) es la tercera, la modernización de Legacy Systems es la sexta y las aplicaciones ERP la novena.

 

 

 

Despliegues grandes en Amazon EC2

16

En Agile Testing explican su experiencia en un gran despliegue en EC2 de Amazon.

Las grandes lecciones a retener, según esta experiencia son:

  • Prepárate para los fallos, es más, considéralos algo positivo en el sentido de que te ayudará a diseñar mejor
  • Automatiza totalmente el procedimiento de despliegue (este le gustará a Abiquo)
  • Diseña para el escalado horizontal (es decir a base de incrementar el número de máquinas/instancias y no aumentando la potencia de las mismas – enfoque vertical)
  • Establece objetivos claros y medibles
  • Prepárate para identificar rápidamente cuellos de botella y eliminarlos
  • No esperes que por muchas pruebas que hagas funcione a la primera.

Este es sólo un resumen, vale la pena leer el artículo original si estás interesado en el cloud computing.

Longjump lleva su plataforma a casa del cliente

longjump-platform

Interesante movimiento de LongJump (proveedor de PaaS Platform as a Service) del que me entero por el blog de Phil Wainewright.

La compañía de California ofrece ahora su plataforma para que pueda ser utilizada en las propias instalaciones de sus clientes. Los talibanes puristas del concepto SaaS se llevarán las manos a la cabeza escandalizados, pero yo creo que es un movimiento muy inteligente por parte de LongJump ya que les permite oponer un potente argumento a los detractores del cloud computing cuando objetan aquello de ¿y que pasa si tu proveedor SaaS te deja tirado?.

Movimiento que además, como ya se comentó aquí mismo, va en línea con los deseos de sus potenciales clientes.

¿Qué le pedirías a tu proveedor de cloud?

En una reciente encuesta de IDC se preguntó a los encuestados qué atributos valorarían más en sus proveedores de servicios Cloud y la respuesta se puede ver en el siguiente gráfico:

Atributos a reclamarle a un proveedor de cloud

 

Como era de esperar precio y calidad (SLA) son los más valorados. Del resto de atributos me llama la atención el cuarto más apreciado, el que hace referencia a que sea posible mover a las propias infraestructuras la aplicación desplegada en la nube del proveedor. Me llama la atención, primero y obviamente porque es diferencial (el resto de atributos podrían serle reclamados a cualquier proveedor, sea cloud o no) y segundo porque creo que la clave no es que la aplicación sea transportable a las propias infraestructuras sino que sea transportable a cualquier otra nube también.

Esta cuestión, la de la portabilidad entre nubes, es en mi opinión uno de los retos, junto con la seguridad y la integración, que antes deben afrontar los proveedores de servicios en la nube si quieren que este concepto despegue.

 

SAP se queda con Coghead

logo_coghead1

Coghead, proveedor de servicios de plataforma de desarrollo en modo bajo demanda (PaaS), tira la toalla y da de tiempo a sus clientes hasta el el 30 de abril para que se lleven sus datos. Se puede leer la carta enviada por Coghead a sus clientes aquí.

Sin duda es un contratiempo para los defensores de este paradigma de creación de aplicaciones de negocio que consiste, recordémoslo brevemente, en crear las aplicaciones utilizando una plataforma o entorno de desarrollo que ofrece bajo demanda y hospedado en sus infraestructuras, herramientas, APIs, librerías de objetos, aceleradores de desarrollo, el entorno donde se ejecuta la aplicación, e incluso un marketplace donde comercializarlas.

¿Invalida este cierre este modelo de negocio? En principio creo que no, pues quedan compañías como force.com y Zoho Creator, por citar quizá las más conocidas, en crecimiento y ganando clientes, pero sí que alimenta uno de los argumentos más utilizados por sus detractores: que un cliente de este tipo de proveedores de servicios corre un alto riesgo en el caso en el que éste cierre, como es el caso. 

El otro lado remarcable de la noticia es que SAP (que era accionista de Coghead) se queda con la tecnología y los ingenieros de la compañía quebrada y este sí que es un punto interesante: ¿Para qué quiere SAP esta tecnología?

  • ¿Para incorporarla a sus productos?, ¿Quizá SAP Businessby Design?
  • ¿Para desarrollar aplicaciones satélite alrededor de sus productos?

En cualquier caso es un movimiento interesante y que, en mi opinión, es un punto positivo a favor de SAP.

 

Entradas relacionadas:

 

Más información:

Uso de cookies

Este sitio web y subdominios asociados utilizan cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies