Aunque podamos tener a primera vista el mismo software si lo vendemos como producto o como servicio, la forma de concebirlos y de gestionarlos es muy diferente. Desde la arquitectura tecnológica que usamos a la forma en que nos organizamos, convertir nuestros software en un servicio es un proceso de transformación integral del departamento de desarrollo responsable de la solución.
Muchos Departamentos de IT están en proceso de evolucionar sus aplicaciones corporativas desarrolladas internamente hacia este nuevo paradigma, pero hay todavía poca experiencia en el mercado en hacerlo de forma satisfactoria. Por un lado, se necesita una alta capacitación tecnológica del equipo, siendo necesario un proceso de formación y adaptación para incorporar el conocimiento necesario.
Y por otra parte, también es necesario reorganizar a nuestro Departamento para implantar las metodologías y procesos de trabajo necesarios para atender a un servicio en constante evo lución. Muchas veces se simplifica pensado que con una actua lización de tecnologías y un cambio a metodologías ágiles ya estamos preparados, pero desafortunadamente no es así.
Replantear nuestras aplicaciones con un enfoque SaaS implica analizar los puntos que detallamos a continuación, auténticos pilares del software como servicio y que requieren ser con templados en el diseño de nuestra nueva plataforma y en el pro ceso de cambio organizativo que requieren. Pero no afrontarlos en su globalidad sólo harán que las frustraciones y los riesgos de tener que volver atrás sean mayores y tengamos que dedicar más esfuerzos y recursos a conseguirlo.
- Aplicaciones adaptables
La aplicación se concibe como un conjunto de servicios orientados al usuario que se adaptan a sus necesidades y roles en el entorno. En las arquitecturas tradicionales se planteaba el pro ducto como un todo y existían diferentes partes que gestionaban ciertos ámbitos como la seguridad o las bases de datos, por ejemplo, pero siendo un producto monolítico.
Las arquitecturas SaaS están formadas por diferentes piezas individuales de software que juntas funcionan pero que sepa radas también lo hacen. Tienen autonomía y se podría decir que son pequeños productos en sí mismos. Al no depender de un ente mayor, sino que cada aplicación funciona de forma autónoma, existe mayor flexibilidad para poder contratar a terceros y utilizar sus piezas con el fin de ofrecer un mejor servicio.
- Redundancia de servicios
Al pensar en una Enterprise App basada en pequeñas piezas se tiene saber cómo comunicarlas y entender que no tendremos control sobre ellas, porqué muchas serán de terceros. Esa es la clave de la redundancia, porque ya no tenemos que preocuparnos sólo por la estabilidad del producto entero sino de cada pieza individual. Es decir, trazar la capacidad de reacción del entorno para que cuando alguna pieza falle, tener un plan B que haga funcionar la aplicación sin que el usuario se tenga que ver afectado por ello.
- Arquitecturas complejas
En un modelo Enterprise SaaS, los usuarios tan sólo necesitan tener conexión a Internet. Las consideraciones de arquitectura, servidores, rendimiento o ubicación dejan de ser relevantes para él y en muchos casos, para el equipo de desarrollo. Gracias a que la infraestructura de la aplicación se basa en servicios en la nube totalmente escalables, los costes para la empresa son mucho menores en relación con los que antes acarreaban las aplicaciones tradicionales y se diseñan arquitecturas mucho más complejas sin necesidad de grandes inversiones.
- Métricas de aplicación
Además del feedback que recibimos de los Key Users internos, los servicios de métricas de aplicaciones que podemos incorporar en nuestras plataformas nos aportan información de vital importancia sobre el comportamiento del usuario. Permiten analizar qué uso se está haciendo de la aplicación y resolver fácilmente cuestiones como: ¿Quién se ha conectado? ¿Qué partes del programa son las más usadas? ¿Con qué dispositivo acceden los usuarios? ¿En qué horarios? Estos y otros datos son los que quedarían recogidos en las Application Insights que varios fabricantes, entre ellos Microsoft, nos ofrecen como servicio de pago para poder obtener valiosa información que nuestros Product Managers agradecerán enormemente.
Application Insights es el servicio que nos ofrece Azure para medir el uso que hacen los usuarios de nuestras aplicaciones.
- Accesibilidad total
Antes el software tradicional implicaba que al salir de las instala iones de la corporación ya no se podía utilizar el programa que se había comprado o que había saltos de permisos o acceso a los datos entre sistemas.
Con el software as a service el producto es multiplataforma, de manera que se puede acceder a él en cualquier lugar y momento usando siempre una única identidad corporativa que extiende el modelo de Single Sign On tanto a los sistemas propios como de terceros.
- Comunicación de novedades
En el Software as a Service el producto está en constante funcionamiento, las 24 horas, 365 días al año. El usuario final no percibe que se está actualizando, ya que la aplicación siempre está disponible en cualquier momento y lugar. Esta invisibilidad de dichos procesos hace que sea importante informar al usuario de las novedades que se han llevado a cabo. Mientras que en las arquitecturas tradicionales, el deploy a una nueva versión comportaba un anuncio formal de novedades, aquí debemos buscar mecanismos in app para notificarlo y que el usuario las aprenda a usar de forma natural.
- Integración continua
El SaaS requiere de una actualización constante del código en producción, sea por pequeñas mejoras o para arreglar defectos. Aquí es clave compartir el roadmap de cambios, no sólo con el equipo de producto sino directamente con los usuarios finales. De esta manera, podemos anticipar cuándo tendrá lugar cada novedad y gestionar las expectativas de los clientes.
La inmediatez de este proceso de integración continua ha definido en pocos años un perfil nuevo en el equipo de desarrollo: el solicitado DevOps, un experto tanto en las tecnologías de desarrollo como en el conocimiento de los entornos de desarrollo y producción para gestionar satisfactoriamente el ciclo de evolución permanente de las aplicaciones.
- Instancias múltiples
En el nuevo escenario global, cada vez más abierto e integrado, las empresas centralizan en centros de innovación el desarrollo de una misma aplicación para toda la empresa. Este modelo multitenant implica que hay que pensar en localizaciones, traducciones y despliegues en varios entornos en paralelo, dado que tendremos múltiples instancias de la aplicación según las necesidades de cada unidad de negocio. Un sistema de Release Management que permita combinar la actualización automática con el control de elementos locales es clave para una buena evolución de nuestro SaaS.
- Equipos ágiles
Dado que está tan de moda entre la comunidad de desarrolla dores el uso de metodologías ágiles, sean Scrum, Agile, Kanban o Lean, poca explicación es necesaria de sus beneficios. Sólo una advertencia: en un Enterprise SaaS, usar estas metodologías de trabajo no debe ser sinónimo de autogestión del equipo de desarrollo, sino de una auténtica capacidad de adaptación a las necesidades de los usuarios finales que, como los clientes, nos guste o no, siempre tienen la razón.
- Nivel de servicio
El concepto de SLA o nivel de servicio tiene años de recorrido y una amplia literatura y experiencia real en muchas empresas, por lo que es sobradamente conocido como implementar sus buenas prácticas. El principal reto es que esta orientación llegue a impregnar las prioridades del equipo de desarrollo, entendiendo que sin una buena atención a los problemas habituales de los usuarios, las nuevas mejoras que creemos se pueden encontrar con que no quede nadie para descubrirlas. Un buen sistema de ticketing junto con métricas de la satisfacción serán herramientas fundamentales para que un equipo de Enterprise SaasS tenga éxito.