Desafío
Como parte de la transformación tecnológica de una compañía es probable que llegue un momento en el que se deba renovar una aplicación o un conjunto de aplicaciones, lo que implicará un cambio del sistema en uso por uno nuevo. Si la compañía utiliza un sistema desarrollado a medida y lo ha implantado en su organización, el proceso de sustituir ese sistema por otro renovado, aunque costoso, puede ser abordable. ¿Pero qué pasa si el sistema que se va a cambiar (sistema legado) es consumido a su vez por decenas de sistemas externos a la compañía? ¿Se puede coordinar que todos esos sistemas externos se adapten de forma transparente, ágil y temprana al nuevo sistema?
Solución
Gracias a la flexibilidad inherente a las soluciones que integran las plataformas para la gestión de las decisiones se pueden abordar los cambios tecnológicos vinculados a la transformación digital de las organizaciones de forma transparente, pero sin que los condicionantes asociados a estos cambios impongan limitaciones en la adopción de la nueva solución.
A lo largo del siguiente artículo abordaremos cómo utilizando una plataforma BRMS (para gestionar Decisiones de Negocio y Reglas) se pueden realizar migraciones tecnológicas complejas de una manera transparente, ágil y segura.
Necesidad de cambio en la era digital
Es frecuente que las grandes compañías tengan implementados sus principales procesos en sistemas legados implantados hace décadas. Estos sistemas suelen estar a su vez soportados por arquitecturas bastante antiguas que aportan poca o ninguna flexibilidad y agilidad ante los vertiginosos cambios tecnológicos y de negocio que se producen hoy en día. Además, son demasiado rígidas a la hora de integrar estos sistemas con los de otras empresas. También es frecuente que a lo largo de los años en estos procesos se hayan ido integrando a estos sistemas legados, de manera rudimentaria, nuevas necesidades de distintos tipos mientras que otras necesidades siguen sin estar implementadas.
Por eso las compañías líderes han estado incorporando diferentes componentes a sus sistemas como un ESB o una infraestructura de microservicios buscando migrar sus procesos a soluciones completas (backend y frontend) más modernas con capas de negocio en forma de servicios web, con los que se puedan conectar externamente de una manera ágil y flexible ante los cambios.
Imaginemos por ejemplo el sistema de emisión de pólizas de una aseguradora. Este sistema debe estar conectado con diferentes canales como: la página web corporativa, la app móvil de la compañía, los comparadores de seguros, los sistemas informáticos de mediadores y corredores de seguros, las webs de venta de productos/servicios que permiten la contratación asociada de seguros (agencias de viajes, fabricantes de automóviles, compañías financieras…). Estas integraciones se han ido haciendo a lo largo de los años, pero supongamos que nuestra aseguradora ahora quiere migrar este proceso a un nuevo sistema de emisión más moderno, flexible y ágil. Debido al alto número de canales con los que están conectadas sus operaciones, la sustitución del sistema legado por otro nuevo implica también coordinar el cambio con los sistemas de un montón de compañías ajenas. Todo esto sin olvidar que muchas de ellas serán organizaciones pequeñas (como es el caso de los corredores) a las que no se le puede pedir que rehagan su integración.
El paso de sistemas legados a nuevas tecnologías
En este punto de la renovación tecnológica (cuando ya se tiene un sistema base renovado en la compañía), el siguiente paso es modificar la conexión con el resto de las compañías a su nueva aplicación. Para ello se pueden tomar varias estrategias: abordar el cambio en cada una de las terceras compañías donde está presente una a una (solución clásica) pidiéndoles adaptaciones para usar su nuevo sistema; o bien proponer alguna alternativa que permita abordar el cambio en todos los clientes a la vez, manteniendo el control de cómo atender sus invocaciones y coordinando el cambio mediante algo similar al patrón de diseño de software Proxy.
De esta manera se desarrollaría una pieza software que actuará como proxy y trabajará desde un único punto durante el periodo de cambio con ambos sistemas (legado y la nueva plataforma). Esta pieza permitiría realizar la misma acción (por ejemplo, la contratación de pólizas) a través del nuevo sistema exactamente de la misma forma que se hacía a través de la antigua plataforma durante todo el tiempo que tengan que convivir.
En estos casos lo que suele pasar es que, aunque el nuevo sistema pueda funcionar parcialmente, aún le falte por cubrir algunas de las funcionalidades del sistema legado. No podemos olvidar que los sistemas legados en las grandes compañías suelen ser muy longevos y que la funcionalidad que se ha ido incluyendo a lo largo de los años suele ser muy alta y no estar claramente documentada. Todo ello implica que, si se hiciera el cambio de golpe del sistema legado al nuevo sistema, podría perderse parte de la lógica de negocio que se aplicaba en el sistema legado hasta hacer que el nuevo sistema incluya esa funcionalidad. Lo que a su vez retrasaría la transformación digital que requiere la organización, ya que habría que esperar hasta que esta funcionalidad estuviera incluida en el nuevo sistema.
Aunque para resolver este problema existen soluciones basadas en tecnologías como podría ser un servidor Apache que realice un control de tráfico y acceso a servicios; en la mayoría de los casos no resulta una solución valida, ya que lo más frecuente es que la redirección dependa de decisiones de negocio que irán evolucionando con el tiempo. Por lo tanto, usar tecnologías de desarrollo de software convencionales para intentar implementar con el patrón de diseño software Proxy del que hablábamos antes (toda la lógica necesaria para determinar cuándo canalizar las peticiones por el sistema legado y cuándo canalizarlas por el nuevo sistema), sería demasiado complejo y tan rígido como construir la nueva solución completa de golpe.
Uso de plataformas BRMS como catalizador hacia la era digital
Para cumplir con la necesidad de cubrir parcialmente los requisitos de la contratación en el nuevo sistema sólo para aquellas casuísticas que ya se han construido completamente, se puede combinar el uso del patrón de diseño Proxy con el uso de una plataforma BRMS. De esta forma se podría construir fácilmente un Servicio de Decisión basado en reglas que se encargue de evaluar ágilmente y en función de las características de las propias peticiones, cuándo el nuevo sistema puede encargarse de tramitarlas y cuándo esas peticiones tendrían que ser tratadas por el sistema antiguo.
Cuando esta pieza está en funcionamiento, los canales externos pueden ir migrando sus sistemas poco a poco modificando únicamente la ruta a la que hacen la llamada, sin tener que hacer ningún desarrollo para adaptarse.
Como es el servicio de decisión el que controla cuando se atiende una petición en el nuevo sistema en base a los datos de la llamada, se pueden modificar los criterios de redirección e ir moviendo las funcionalidades poco a poco según las necesidades de la empresa.
Conclusión
En resumen, usar una plataforma BRMS permitirá que los sistemas externos se integren rápidamente, aunque el sistema nuevo aun no tenga todas sus funcionalidades incluidas; del mismo modo que permitirá cambiar fácilmente la redirección de forma completa o parcial según se vaya completando la inclusión de dichas funcionalidades en el nuevo sistema.
Como extra, esta solución también permite que en caso de que ocurran incidencias complejas en el funcionamiento del nuevo sistema, se modifiquen las reglas del servicio de decisión de forma fácil y rápida para que las peticiones afectadas vuelvan a ser procesadas por el antiguo sistema, sin afectar al funcionamiento de la organización y dando tiempo a que los equipos de desarrollo solucionen las incidencias en el nuevo sistema. Del mismo modo, la creación de nuevas reglas o la modificación de las reglas existentes también permitirían quitar carga de trabajo a los servidores del nuevo sistema para aquellos casos en los que los problemas residan en la nueva infraestructura sobre la que está montado, todo ello mientras se soluciona el problema de fondo.
