Actualmente, en nuestro Personal Financial Store tenemos dos tipos de información sobre las órdenes que realizan nuestros clientes.
Órdenes en curso.
Muestra el estado de las órdenes hasta que pasan a la sección de ordenes realizadas. Pero en esta sección aparecen órdenes con el estado "Finalizado" ¿Qué significa? El estado "Finalizado" significa que la orden ha sido lanzada a las gestoras, en el caso de los fondos de inversión, y que se ha finalizado el proceso en nuestro PFS.
Pero el estado "Finalizado" no significa que el proceso haya finalizado para el cliente por eso nos planteamos que debíamos mejorar la información del estado de las órdenes y, ya que nos poníamos a mejorarlo, también sería interesante mejorar la forma de informar a los clientes.
Así que nos embarcamos en 2 proyectos:
Comunicación de los cambios de estado de las órdenes.
Lo mejor sería comunicarle al cliente cuando se produce un cambio de estado en una orden.
Para eso existe una arquitectura de software denominada arquitectura por eventos en la cual un proceso se suscribiría a un evento de cambio de estado y enviaría la comunicación, correo electrónico o SMS, al cliente.
Desafortunadamente este tipo de arquitectura no está muy difundida y, aunque existen servicios en todas las plataformas, Cloud Azure Event Hub, Amazon Kinesis o Gooble Pub/Sub e incluso se escuchó mucho hablar de Kafka como la solución Big Data al proceso de información en tiempo real, lo cierto es que la implantación de los mismos no está tan extendida como debería.
Si no tenemos esta posibilidad ¿Cómo lo hacemos? Es sencillo, hay que preguntar uno a uno a todos los clientes si tienen una orden que ha cambiado de estado en las últimas 24 horas.
Esto significa que, si realizamos el proceso de manera secuencial, el tiempo se incrementará linealmente cuantos más clientes y transacciones tengamos. Es decir, existe la certeza de morir de éxito aunque tengamos 24 horas para realizar el proceso.
Aquí es donde comienzan las ventajas de utilizar los principio de diseño de arquitecturas cloud y donde estas arquitecturas cloud son un cambio de paradigma.
En concreto, para este proceso destacamos, de los principios de diseño cloud que aparecen a continuación, el "Diseño para escalado horizontal".
Ese escalado horizontal se traduce en la capacidad de ejecutar cada petición de cada cliente en paralelo o por lo menos la capacidad de decidir el grado de paralelismo, cuántos a la vez, podemos tener.
En una arquitectura tradicional necesitaríamos un equipo de diseño sobresaliente para hacer los cálculos de cuántos servidores, con cuantos procesos por procesador, memoria, comunicaciones, etc. O simplemente haríamos algo más sencillo, comprar lo mejor y más grande posible que así no nos equivocamos. El problema es que eso no tiene en cuenta el principio de diseño: "Diseño para las necesidades de la empresa".
La solución actual es la computación sin servidor, que no es que los servidores no existan. Es que no nos tenemos que preocupar por ellos, nos tenemos que preocupar de lo que queremos hacer. ¿Qué hacemos ahora con el departamento de infraestructura informática de las empresas? Lo mismo se están preguntando los responsables de esos departamentos que suelen suponer el 50% del coste de tecnología, ¿Qué va a ser de mi? Ahora es más fácil entender porque la "transformación digital" cuenta tanto en algunas empresas. Esto se resumen en otro principio de diseño Cloud "uso de servicios no infraestructura" .
Pero y si, además de no usar infraestructura no necesitase programas y solo necesitase utilizar servicios para leer la base de datos y enviar los correos. Bueno, en ese caso estaríamos hablando de:
Azure Logic Apps
Esa es la tecnología que hemos utilizado en IronIA Fintech para realizar este proceso.
Mediante la programación gráfica, arrastrar cajas, utilizamos las API de Allfunds y los servicios de correo de SendGrid para poder enviar a nuestros clientes un correo electrónico con los cambios de estado de las órdenes.
Este servicio nos permite controlar la paralelización de cualquier proceso repetitivo.
Azure Logic Apps emplea conectores para realizar acciones o desencadenadores en otros servicios u aplicaciones de forma que se convierte en un orquestador de procesos, que es justo lo que necesitábamos, verdaderamente el número de conectores es notable y la facilidad de uso hace que cualquier persona pueda realizar procesos complejos con mucha sencillez.
Pero que sea sencillo no significa que no sea profesional y que no este diseñado para la operación, el servicio cuenta con todos los elementos necesarios para la monitorización, incluyendo alarmas y procedimientos de recuperación automática.
Con un sistema de diagnostico y revisión. de las ejecuciones.
Estas nuevas arquitecturas requieren nuevos profesionales no solo de tecnología sino de cualquier disciplina que diseñe procesos de negocio, por eso IronIA Fintech colabora en el Master en Arquitectura de Datos Cloud del Instituto BME, donde aprovecharemos la tecnología cloud para diseñar procesos de datos como el descrito.
Pondremos este sistema en marcha a partir del lunes 26 de Abril para que todos los clientes podáis recibir los estados actuales a la espera del siguiente proyecto.
Ampliar los estados una vez que la orden sale de IronIA.
Este es un proyecto que no depende de nosotros ya que el detalle del estado de las transacciones lo tiene que proporcionar cada una de las gestoras y ese estado debe viajar de sistema en sistema hasta que se lo podemos mostrar a nuestro cliente.
Así que, en este proyecto nos tocaba utilizar nuestro encanto personal y convencer a Allfunds de la necesidad de mejorar su API para poder obtener la información de los estados de forma más detallada.
Aquí, hay que reconocer que entre el exhaustivo conocimiento que tiene nuestro compañero Alvaro Jabón de la operativa de fondos y la buena disposición de Allfunds a escuchar y mejorar, no fue complicado.
A partir del 18 de Mayo del 2021 la comunicaciones recibidas contendrán el detalle de lo que ocurre una vez la orden sale de IronIA.
Cuando el equipo es bueno el trabajo en equipo supera al individual.
Comments