CIOs Connected pretende compartir experiencia con los “semejantes” del sector asegurador. Una iniciativa enmarcada en la Comunidad WOLF, para aprender de las experiencias vividas por los CIOs de SISnet y conocer cómo han resuelto sus retos en cada una de las iniciativas que han emprendido en el ecosistema. CIOs connected se presenta como un perfecto foro para identificar nuevos procesos de transformación integrando diferentes retos de negocio sobre la órbita tecnológica de SISnet.
El núcleo del debate tecnológico de CIO´s Connected tuvo lugar en un detallado Start Challenge. Una dinámica pensada para poder agilizar las opiniones de los CIO´s con el objetivo de buscar soluciones tecnológicas y de negocio a 3 retos fundamentales:
Challenge 1 # Integración Continua
Incluyendo “Objetos complejos” en la integración continua
Si algo quedó claro en el punto de partida del START CHALLENGE fue que el proceso de despliegue en SISnet está viviendo una metamorfosis que le acerca cada vez más a un modelo de Integración Continua. En el debate en cuestión de esta evolución tecnológica que tuvo lugar durante “CIO’s Connected” se pudo ver un punto común: La evolución del ecosistema se está viendo marcada por el camino a la automatización cada vez más compleja.
La principal preocupación de esta complejidad y un punto de amplio debate para los SISnet Evolvers ha sido la incorporación de los datos complejos. Un reto que todo el parque SISnet tiene por delante y que está en vías de adoptar para complejidades como la que por ejemplo presenta la incorporación de nuevos ramos a los que ya se tienen en producción.
Actualmente SISnet ofrece un conjunto de herramientas que comprende un alto porcentaje de elementos susceptibles de ser incluidas en el flujo de Integraciones Continuas. El uso de SCM, Maven o herramientas ALM que proporciona SISnet Studio y otras tecnologías como Jenkins, permiten automatizar distintas fases del proceso. El reto que se presenta ahora mismo a los SISnet Evolvers es resolver la existencia de esos “objetos complejos” que actualmente no permiten la adaptación de los procesos en su totalidad.
En busca de soluciones, la conclusión más potente que salió a flote en este brainstorming que los Evolvers trabajaron para atajar las complejidades que representa la integración de datos complejos, fue la idea del desarrollo de un gestor de despliegues automáticos personalizado para SISnet. Un gestor que permita la implantación en los entornos disponibles de cada desarrollo. Esto permitiría ampliar la funcionalidad del componente e incluir “objetos complejos”, como por ejemplo las reglas.
Decidiendo juntos lo que automatizamos
Que la Integración Continua representa un reto de gran relevancia para las aseguradoras es una realidad. SISnet es una plataforma totalmente transversal, y como tal, ya podemos ver como se está trabajando para que su ecosistema permita incorporar todas las pruebas de Integración Continua que sean necesarias.
Uno de los puntos de interés de los Evolvers y que enriqueció el debate del Challenge sobre Integración Continua, es que SISnet como producto “core” que es, a veces esperamos ver una evolución cuyo camino debería tender la mano a una automatización prácticamente absoluta.
¿Pero esto es así realmente? Por la propia estructura de la plataforma, los Evolvers concluyeron que en realidad debemos tener en cuenta que hablamos de un proceso laborioso de poder llevar a cabo en las distintas etapas de pruebas (unitarias, funcionales, de aceptación de usuario). Y es que la realidad nos dice que el análisis de estas circunstancias nos demuestra que no todas las pruebas deben incluirse en el proceso. Es de vital importancia definir muy bien los casos de uso que son susceptibles de ser automatizados, casos que realmente aporten un valor y una calidad entregable.
En la actualidad se están realizando automatizaciones de pruebas funcionales como parte del proceso de Integración Continua y lo cierto es que no hay problema en incorporar estas pruebas a dicho modelo. Esto está permitiendo que cada vez que se realiza un despliegue, éstas sean ejecutadas.
Lo importante en este paradigma viene por la adopción de una metodología de trabajo a la hora de realizar automatización de pruebas de regresión, de manera que el mantenimiento de las mismas conlleve el menor esfuerzo y además sea lo menos costoso posible.
Adaptando nuestros deadlines a la evolución de SISnet
La necesidad de adaptar los deadlines de desarrollo en paralelo a la evolución de SISnet fue una reflexión que abrió una nueva tangente en el debate de los SISnet Evolvers.
Debido la evolución constante del producto, todas las personalizaciones que se realizan para adaptarse a las necesidades de los diferentes clientes deben estar lo más alineadas posible con el core. Esta es la única manera para que no haya problemas de integración con los diferentes versionados de SISnet.
SISnet es un producto core con un roadmap de evolución tanto técnico como de expansión de capacidad core en el ámbito asegurador. Se podría decir que al convertirse en el core de las aseguradoras que lo implantan, el “SISnet de Referencia” adquirido, acaba durante su implantación en una “Variante del SISnet de Referencia” para adecuarse a las características del negocio de la propia entidad aseguradora.
Es por ello, que para aquellas entidades que se planteen iniciar una implantación de SISnet, es importante analizar y definir cuál va a ser la estrategia más adecuada conforme a las capacidades técnicas de SISnet para llevar a cabo estas adecuaciones en el producto. De no ser así, será muy costoso para las entidades aseguradoras poder realizar upgrades o seguir el ritmo evolutivo de SISnet, además de no poder aprovecharse de las futuras nuevas capacidades del producto.
A la hora de plantear la mejor estrategia para convertir SISnet en la variante que la entidad aseguradora necesita, es importante llevar a cabo estas variaciones (en la medida que se pueda) de la forma más desacoplada posible.
De esta forma, cuando se proceda a realizar un upgrade de SISnet, se podrá realizar una matriz de impacto para cada una de las variantes desacopladas. Esto permitirá poder trazar una hoja de ruta para adaptarlas si se requiere, pero de esta manera no se vería afectado el core, puesto que los upgrades deberían darse de caja por parte del producto los upgrates de una versión a la siguiente. A su vez, implementar las variantes de forma desacoplada ayudará a poder evolucionarlas relativamente de forma más independiente del producto.
Challenge 2 # Quality Assurance
Aplicando QA a pruebas funcionales y unidades mínimas
Los Evolvers cada vez nos dejan más claro que las iniciativas Quality Assurance (QA) en el entorno SISnet están alcanzando un importante grado de madurez. En el inicio de este segundo Challenge hemos podido apreciar que cuando hablamos de automatizar pruebas funcionales aplicadas a flujos completos con tecnologías en torno a Selenium WebDriver y Cucumber, la aplicación de QA en ya es una absoluta realidad. Gracias a esta metodología, los Evolvers nos demuestran como están consiguiendo una importante reducción de costes en los procesos de puesta en producción de nuevas funcionalidades.
Si bien queda un largo recorrido en cuanto a aplicar QA más allá de las pruebas aplicadas a circuitos completos, en este sentido sería un gran avance aplicar QA a unidades mínimas funcionales. De esta manera, los tiempos de desarrollo se verían acortados exponencialmente, puesto que la automatización de las pruebas mínimas, permitirían ir automatizando al mismo tiempo que se va implementando.
Esta situación también permite agilizar las pruebas en aquellos flujos existentes, haciendo hincapié en los pasos finales del proceso en los que las pruebas son laboriosas. El foco inicial para la aplicación de QA a pruebas unitarias se ha realizado desarrollando un módulo (análogo al de Simulador ya existente) que permite comprobar la funcionalidad de una o varias reglas de negocio de forma temprana.
Aplicando tecnología a la automatización
Muchas compañías poseen amplios volúmenes de pruebas de regresión desarrolladas sobre otros sistemas. Esta situación les permite validar la calidad de las funcionalidades implantadas en producción.
La duda que se plantearon los Evolvers en el ecuador del Challenge QA, fue sobre el cambio de entorno sobre el que se realizan las pruebas de automatización y su adaptación al core de SISnet.
Las conclusiones más importantes en este aspecto es que ante estos casos hay que tener en cuenta la tecnología sobre la que se aplica la automatización, ya que dependiendo de ésta, la herramienta empleada para ello varía.
Para el caso de SISnet, no hay problema en emplear Selenium para la automatización de pruebas, sin embargo, para los casos en los que se dispone de un Front desacoplado, y éste está desarrollado en tecnologías como puede ser Angular, el framework a utilizar sería Protractor.
Definiendo juntos validaciones unitarias
El Challenge de QA cerró con una cuestión muy importante para todos los Evolvers. Lo que aquí se planteó fue que dentro del marco de testing se puede llevar a cabo la validación de unidades mínimas como las reglas de negocio y el cálculo de la tarifa y que además, esto permite realizar validaciones sin necesidad de validar el proceso de negocio de forma completa. ¿Pero cómo aprovechamos todo el potencial que ofrece esta funcionalidad?
Lo importante en este punto es que se deben definir los diferentes casos de uso más adecuados para cubrir con los requerimientos de negocio establecidos en cada caso. Además, debemos tener en cuenta que el core permite la validación de las pruebas definidas sobre este módulo desde aplicaciones externas mediante el uso de APIs.
Realizar validaciones unitarias en cada uno de los entornos que forman parte del circuito en los que se promociona los distintos desarrollos permitirá maximizar la calidad y mitigar el riesgo en un entorno multi desarrollo. Es recomendable definir un conjunto de validaciones funcionales unitarias independientes, pruebas básicas, que permitan segmentar las pruebas para asociarlas a cada equipo de desarrollo.
Challenge 3 # SISnet Cloud
El reto de la nube
El tercer Challenge se abrió con una potente convicción: Ir al Cloud representa para muchas compañías aseguradoras una verdadera decisión estratégica.
La alta disponibilidad, la escalabilidad de la nube donde la disponibilidad de recursos es virtualmente infinita y los niveles de acuerdo de servicio son superiores al 99,99%, en cualquier zona geográfica del mundo son las principales motivaciones que promueven la implantación de SISnet en la nube.
Para afrontar las complejidades de la decisión de si ir o no a la nube, es importante que se tenga en cuenta que el motivo de mayor peso es el ahorro de costes. Hay que tener muy presente que el diseño de la solución debe contemplar en su diseño el “apagado”. Uno de los mayores errores es pensar en Cloud y seguir diseñando la solución como si fuera “on-premise”, si esto ocurre, no sólo no se conseguirá el objetivo, sino que incluso el coste puede ser mayor.
Para esta contemplación, es interesante conocer la capacidad de nuestro producto en cuanto a su arquitectura técnica y su modularidad, para establecer la estrategia de apagado más adecuada y rentable para las compañías.
La verdadera rentabilidad del Cloud
El Challenge tuvo su meridiano en una complejidad concreta. Algunos Evolvers nos comentan en este punto de la sesión que cuando hay una gran escalabilidad en el servicio y se hace números, parecería que al final sale mejor seguir en On Premise. Como si pareceiera que la nube tiene muchos costes de escalabilidad asociados.
Lo cierto es que escalar nunca fue un proceso demasiado económico, pero aquí la cuestión, para no disparar los costes en la nube, pasa por tener clara la unidad mínima que requiere escalar en cada momento.
Es muy importante tener en cuenta esta realidad ya que intentar escalar un core como un monolito, puede ser una auténtica ruina.
Queremos encender y apagar la máquina
Cerrando el Challenge SISnet Cloud, los Evolvers nos plantean una cuestión muy interesante. Nos comentan el paradigma al que se enfrentan al utilizar un Amazon Privado por ejemplo, con las ventajas e inconvenientes que ello supone.
Ellos se dan cuenta que através de este Cloud, todos los sistemas de seguridad ya vienen resueltos. Todo consiste en llega y desplegar. El problema que ven es que los números salen en el momento que puedes “encender y apagar”. Si se complica el tema de ALM y de entornos, o empiezas a apagar maquinas o sino empieza a no salir rentable.
Las conclusiones más relevantes a estas complejidades nos demuestran que aprovecharse de los servicios que ofrece la nube es la solución más rápida a la hora de realizar implantaciones de un core. Esto permite reducir al máximo el desarrollo de piezas de arquitectura por parte de la entidad.
Explotar al máximo los servicios de seguridad, monitorización y DevOps que ofrecen los Clouds es la clave para el ahorro de tiempo y dolores de cabeza.
