La orquestación de los procesos bancarios es el camino para hacer coexistir plataformas legacy y nuevos servicios cloud‑native. Este es un camino dictado por las necesidades de los clientes: el mercado global de las plataformas para Digital Banking crecerá a una tasa de crecimiento anual compuesta (CAGR) del 10,66 % en el período 2024‑2033. Así se desprende de un estudio de Grand View Research, que identifica entre las razones de este desarrollo la creciente demanda de los clientes de servicios en movilidad, pagos online y gestión remota de sus cuentas.
Dicha demanda acelera el desarrollo de servicios cloud‑native o híbridos, que ofrecen elasticidad, resiliencia y prestaciones no disponibles de otro modo. Las aplicaciones legacy, que no poseen estas características, reúnen sin embargo décadas de lógica empresarial que las compañías no pueden sustituir fácilmente: los softwares tradicionales son estables y fiables; los costes de desmantelarlos son mayores que los de mantenerlos activos; las competencias necesarias para la migración son escasas; por último, el resultado de las operaciones es incierto.
El único camino viable es crear una arquitectura aplicativa en la que puedan integrarse los sistemas legacy y los nuevos servicios cloud‑native. Es decir, es necesaria una orquestación que integre las plataformas legacy con los nuevos servicios digitales.
En este artículo descubrirás:
para qué sirven hoy los sistemas legacy en el sector financiero;
por qué los sistemas legacy son importantes y estratégicos;
cómo integrar los sistemas legacy con los servicios digitales en la nube;
qué significa orquestar servicios y cómo hacerlo en la práctica.
La evolución del mercado financiero tiene en el Open Banking uno de sus paradigmas de referencia. No es casual, por tanto, que normativas como, por ejemplo, FIDA – Financial Data Access, regulen el intercambio de datos entre las instituciones financieras. Los nuevos servicios (embedded services, Banking‑as‑a‑Service, etc.) o los nuevos modelos de negocio (FinTech) diseñan flujos de trabajo que involucran aplicaciones pertenecientes a distintos sujetos.
Como consecuencia, ha nacido la API Economy – Application Programming Interface, que se basa en tres pilares:
la API es el medio para conectar aplicaciones diferentes;
la nube es la tecnología habilitadora para desarrollar software altamente flexible y escalable;
los orquestadores como Kubernetes gobiernan y coordinan el conjunto de los servicios.
Los sistemas legacy, que desempeñan un papel esencial en los nuevos procesos digitales, deben formar parte integrante de la orquestación.
En la banca, la coexistencia entre sistemas legacy y nuevos servicios digitales representa siempre un desafío. Las aplicaciones móviles y los nuevos paradigmas de servicio (pagos online, smart spending, etc.) requieren a menudo la activación de aplicaciones de back‑end, por lo general muy complejas.
Piénsese, por ejemplo, en la transferencia instantánea: el sistema de core banking legacy y el motor antifraude son consultados para las correspondientes verificaciones, y la operación debe completarse en pocos segundos. Además, los procesos del Digital Banking no incluyen solo operaciones internas a la organización. El embedded banking o el Banking‑as‑a‑Service, por ejemplo, incluyen actividades externas que contemplan, nuevamente, operaciones de back‑end.
Las plataformas legacy, sin embargo, nacieron antes de la nube y con paradigmas arquitectónicos distintos, y resultan estructuralmente incompatibles con el cloud. El legacy fue concebido y se desarrolló como plataforma on‑premise, monolítica, en la que la interfaz con el exterior se limitaba a la recepción o envío de datos (File Transfer), necesarios para elaboraciones batch de tipo procedimental. Incluso las actividades transaccionales de oficina y el acceso en tiempo real a las bases de datos se realizaban en una red cerrada, diseñada, configurada y controlada por plataformas centralizadas específicas.
Los nuevos paradigmas de comunicación (Internet), de deslocalización de los recursos de procesamiento (nube) y de interconexión entre aplicaciones (API), dejan fuera de juego a los sistemas legacy. Estas plataformas contienen, sin embargo, un patrimonio empresarial irrenunciable: bases de datos históricas, lógica aplicativa refinada a lo largo del tiempo y procesos de eficacia comprobada.
La migración completa, es decir, la reescritura en clave cloud‑native, es teóricamente posible, pero en la práctica se enfrenta a importantes criticidades: el coste de reescritura es muy elevado; la transformación completa es un camino incierto y expuesto a altos riesgos; por último, las competencias necesarias para dominar las lógicas legacy no son fáciles de encontrar, ni dentro ni fuera de la organización.
El mismo razonamiento se aplica a aplicaciones fuertemente personalizadas, que, incluso si han sido desarrolladas con arquitectura cloud, deben considerarse legacy a todos los efectos: una reingeniería completa, aunque deseable, resulta muy exigente debido a los costes y los riesgos.
Existen muchos ejemplos, en el ámbito bancario, de procesos en los que una parte de las actividades sigue vinculada a entornos legacy:
Disponibilidad de fondos (Balance Check). El registro contable y las lógicas de posting (registro oficial de las transacciones) nacieron en mainframe y garantizan de forma absoluta la consistencia del dato.
Pagos digitales. La autorización de la tarjeta es la parte más crítica del proceso debido a las certificaciones con los circuitos interbancarios y suele residir en sistemas legacy.
Apertura de cuentas corrientes digitales. La carga de la información del cliente y la apertura de la cuenta en el core banking son procesos legacy, fuertemente integrados con distintos sistemas y que requieren verificaciones de compatibilidad con las políticas históricas de la empresa.
Préstamos instantáneos. El motor de concesión del préstamo y el plan de amortización se basan en lógicas financieras complejas alojadas en sistemas legacy.
Una evolución y modernización de las aplicaciones legacy es, en cualquier caso, necesaria, porque, si permanecen en su estado actual, no es posible integrarlas en los nuevos procesos digitales: la antigua plataforma monolítica necesita formar parte de un nuevo proceso y, por tanto, interconectarse con otras partes del flujo.
El recorrido de modernización de los sistemas legacy puede realizarse a distintos niveles, en función de la complejidad de las aplicaciones y de las propias actividades de migración. Las diferentes opciones se conocen como las “5R”:
Rehosting. Traslado de la aplicación “tal cual” a la nube, sin modificaciones del software;
Refactoring. Reescritura parcial del código para introducir lógicas de mantenibilidad y modularidad típicas de las aplicaciones cloud‑native;
Replatforming. A diferencia del rehosting, el código se adapta para aprovechar mejor los servicios de la nueva plataforma, por ejemplo las modalidades de acceso a bases de datos;
Rebuild. Reescritura completa de la aplicación según una lógica de microservicios;
Replace. Sustitución de la aplicación por una solución completamente nueva, a menudo bajo un modelo comercial SaaS – Software‑as‑a‑Service.
La elección de una de estas opciones es estratégica, no solo técnica: se hacen explícitos los límites funcionales de una aplicación, que participa en la orquestación global mediante una lógica basada en API y eventos. Las lógicas legacy permanecen iguales, pero pasan a formar parte del ecosistema del Digital Banking como microservicios dentro de contenedores reutilizables.
La transformación de las antiguas arquitecturas legacy en servicios invocables bajo demanda implica no solo la elección del nivel de intervención, sino también el diseño de la nueva arquitectura aplicativa.
En los procesos bancarios citados anteriormente, es necesario transformar la parte vinculada a los legacy en pasos de un flujo coordinado. La orquestación de los servicios bancarios requiere, por tanto, una serie de intervenciones técnicas externas a la lógica del software en sí:
Containerización de las aplicaciones. El software se “empaqueta” en un contenedor estándar que garantiza su portabilidad entre entornos y aplicaciones. El software se aísla y se invoca cuando es necesario, garantizando la escalabilidad en el uso.
Orquestación. Motores como Kubernetes gestionan el ciclo de vida de los contenedores (deploy, instanciación, escalado, etc.). Kubernetes permite que los módulos de software estén disponibles para su ejecución, creando una aplicación distribuida.
API management y API gateway. El software expone sus funcionalidades de forma estándar, permitiendo su uso por parte de otros sistemas. Tanto el ciclo de vida (versionado, invocación, etc.) como el contexto de uso (autenticación, seguridad, etc.) deben diseñarse y gestionarse adecuadamente.
Integración síncrona o asíncrona. El microservicio puede diseñarse para un uso síncrono (respuesta inmediata) o asíncrono (ejecución mediante colas o eventos). Ambos enfoques se combinan para equilibrar latencia y capacidad de respuesta. Una correcta orquestación de los procesos bancarios debe tener en cuenta el equilibrio adecuado entre ambos modos. En el caso de la transferencia, por ejemplo, es aconsejable separar los servicios que deben ejecutarse obligatoriamente de forma síncrona (autenticación del usuario, comprobación del saldo, validación del IBAN, etc.) de aquellos que pueden ser asíncronos (registro en el libro mayor, envío al circuito interbancario, etc.).
La integración de los sistemas legacy del banco, es decir, la orquestación aplicativa, es realmente posible gracias a un trabajo progresivo de desacoplamiento y modernización, basado en la creación de microservicios containerizados gobernados por Kubernetes.
El nuevo modo de desarrollar servicios ha creado, de hecho, un nuevo ecosistema que requiere actividades específicas: la Observability, es decir, la monitorización de las aplicaciones y de los recursos de procesamiento para garantizar disponibilidad y niveles de servicio; la Continuous Integration / Continuous Delivery (CI/CD), para automatizar, según el modelo DevOps, las fases de desarrollo y despliegue del software; por último, la gestión de accesos (tokens, contraseñas, certificados, etc.) para proteger funciones y datos sensibles.
El problema de la seguridad tiene, como es evidente, un valor fundamental. El uso de la nube y el nuevo paradigma del software distribuido exponen las aplicaciones a múltiples riesgos. No es casual, por tanto, que existan diversas normativas que obligan a las entidades bancarias a construir defensas adecuadas contra el robo de datos o el uso fraudulento de los servicios.
Las normativas FIDA, PSD2 (PSD3 en perspectiva) y DORA proporcionan indicaciones claras sobre los riesgos posibles y las contramedidas necesarias. Orquestar los procesos bancarios significa, por tanto, gestionar aspectos específicos de seguridad, que pueden referirse tanto al uso de la aplicación (la PSD2 introduce la autenticación fuerte para el acceso a los servicios) como a la creación de entornos protegidos frente a interrupciones operativas o ciberataques.
La evolución del mercado financiero (Open Banking) y la competencia de las empresas FinTech obligan a los bancos a crear servicios digitales alineados con las expectativas de los clientes: el mobile banking, los embedded services o el Banking‑as‑a‑Service son ejemplos de servicios digitales innovadores que, para desarrollarse, necesitan integrar software y datos gestionados por aplicaciones legacy.
La integración de los sistemas legacy del banco requiere, sin embargo, una orquestación aplicativa: los servicios legacy deben aislarse del entorno antiguo y migrarse hacia una nueva arquitectura. Se trata de una actividad crítica, tanto por la complejidad y estratificación de las aplicaciones legacy como por las nuevas lógicas de gestión requeridas por las arquitecturas de microservicios y la containerización.
Por ello, es conveniente adoptar recorridos de transición adecuados que contemplen:
el tipo de migración (5R);
las técnicas del nuevo ecosistema (DevOps, API management, etc.);
el uso de un motor de orquestación como Kubernetes.
De este modo, es posible crear una orquestación aplicativa de los procesos bancarios, es decir, una integración de los servicios legacy que permite valorizar todo el patrimonio aplicativo y garantizar el desarrollo futuro del negocio.