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:

Acceso con Browser as a Platform. El acceso a la aplicación debería poder hacerse sin necesidad de instalaciones de software específico en local. Lo habitual es que sea a través de un navegador estándar (mejor que no se dependa de uno en concreto) con AJAX, HTML5 y algún plug-in tipo ActiveX, Applet, …aunque esto último mejor evitarlo. También es de esperar que avances recientes en protocolos a nivel de aplicación como SPDY y Web Sockets de HTML5 mejoren latencias y rendimiento de los actuales protocolos HTTP… pero esto ahora está en los laboratorios.

De esta forma se consigue:

• Conectividad. Será más fácil acceder a la aplicación
• Facilidad de despliegue. En la implantación no se debería tener que invertir en hardware de terminal de usuario
• Facilidad de evolución. La aplicación podrá evolucionar desde el lado de servidor sin tener que actualizar nada en los clientes – facilitando así al proveedor el mantener una versión única de su aplicación para todos sus clientes

Un tema colateral importante aquí es la conectividad de dispositivos locales como impresoras, PLCs, sensores industriales, etc. pero lo trataremos en el punto de integración.

• Qué productos/tecnologías va a utilizar para gestionar su plataforma Cloud: virtualización, despliegues de aplicaciones (nuevos clientes y/o versiones/parches), creación de nuevos entornos/instancias, gestión de los cambios de versión de productos base (sistema operativo, bases de datos, …), sincronización entre entornos de desarrollo, test y producción, compaginar instalaciones compartidas con dedicadas, etc.
• Si la plataforma física es propia o de un tercero proveedor de PaaS (Force.com, Google App por ejemplo) o IaaS (Amazon AWS, Microsoft Azure, IBM, etc.). Este punto, además tiene relevancia a efectos legales, como veremos más adelante en esta serie.
• Si dispone de herramientas o tecnologías específicas para la gestión de grandes volúmenes de datos o cómo va a asegurar la escalabilidad de un entorno de datos que al ser compartido va crecer más y de forma menos previsible de lo que lo hace en un escenario no compartido. Sin llegar a los extremos de tener que disponer de tecnologías de Big Data pero creo que no vale el enfoque por el que se optaría en una instalación monocliente (el Multy-tenancy aparece otra vez) al ser potencialmente un entorno menos predecible y planificable.

• Contingencia. ¿Qué pasa si hay una incidencia que hace que las instalaciones (o parte de ellas) donde residen las infraestructuras dejen de estar operativas o incluso son destruidas?,  ¿Cómo lo ha previsto el proveedor y cómo se integra en nuestra estrategia de recuperación del negocio en caso de desastre (Disaster Business Recovery Plan)?, ¿Hay redundancia de equipamientos como líneas de comunicaciones, alimentación eléctrica, generador/grupo electrógeno, etc.?, ¿Dispone el proveedor, o nosotros, de una instalación de respaldo alternativa para el caso de un desastre total, y en ese caso cómo se efectuaría la transición?,  ¿y la sincronización de datos entre instalaciones?
• Rendimiento ante picos de actividad, algunos predecibles y otros no, inestabilidad del entorno por el cambio continuo, … ¿Qué tecnologías va a utilizar el proveedor para garantizar el rendimiento de la plataforma, velocidad de las líneas, uso de recursos de CPU, …? De la misma forma que con la escalabilidad de datos, las estrategias y arquitecturas tecnológicas que se han venido utilizando en instalaciones single-tenancy es probable que no sean las más adecuadas.
• Seguridad física. ¿Cómo se controla el acceso físico a las instalaciones?, ¿Quién tendrá acceso?, ¿Sistemas de vigilancia/registro/grabación?, …
• Monitorización. ¿Cómo va a controlar el proveedor el rendimiento y disponibilidad de la plataforma? Lo mejor es que el proveedor os enseñe su centro de control y que os explique qué herramientas de control y gestión de alarmas utiliza y cómo os vais a enterar si hay una incidencia. Volveremos sobre esto en el punto de gestión del servicio.

• Cómo se gestionan las copias de seguridad: Periodicidad (diaria, cierre de periodo/ejercicio, …), quién lo hace, dónde se gestionan/almacenan las copias, control de acceso, …
• Cómo es la sincronización con posibles centros de respaldo
• ¿Se cifra la información sensible (más sobre esto en la entrada sobre privacidad)
• Cómo se controla el acceso a la aplicación, a la base de datos, etc. tanto accediendo desde dentro como desde fuera del firewall/perímetro de seguridad.
• ¿Se registra/audita la actividad de acceso a datos? Qué, quién y cuándo se modifican/leen/borran los datos
• Cómo se asegura que otros clientes no ven mis datos
• etc. no me extiendo más en este punto porque entiendo que hay disponible abundante documentación al respecto.

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