Abrir puertas con la banca orientada a API
Por: Pannerselvam D, AVP, Intellect Design Arena
Los servicios basados en la nube como SaaS (Software as a Service), PaaS (Platform as a Service), IaaS (Infrastructure as a Service) y NaaS (Network as a Service) se han convertido en palabras de moda en el mercado. Según un informe, se calcula que el mercado mundial de la computación en nube alcanzará la friolera de 219.000 millones de dólares en 2020, y es probable que crezca hasta los 791.000 millones de dólares en 20281. Aunque la pandemia desempeñó un papel clave en el paso de las empresas a la nube, hubo otros factores que contribuyeron a este cambio. Algunos de ellos fueron el menor coste de mantenimiento, la mayor adopción de tecnologías como IA y ML y el aumento de la financiación en la nube por parte de los países desarrollados.
Aunque tiene sentido que los bancos se pasen a la nube para mejorar la escalabilidad, reducir las molestias de mantenimiento y los costes, la migración a la nube no siempre es la solución. A medida que el banco crece, también lo hacen sus productos y las aplicaciones que los soportan. Lo que puede ocurrir es que estas aplicaciones sigan funcionando en silos. Por defecto, eso significa que el banco no tiene la visión completa. No es sólo esto, hay más.
¿Cómo debe prepararse un banco para una escala continua? ¿Pueden ser las API la respuesta?
Como ya se ha mencionado, uno de los principales problemas a los que se enfrentan los bancos es la gestión de varios tipos de aplicaciones en su entorno informático. Cuando hay un gran número de aplicaciones, la interconexión de las mismas se convierte en una tarea engorrosa. Tomemos el ejemplo de una institución financiera diversificada líder en la región APAC que ofrece una gama completa de productos y servicios financieros tanto a clientes institucionales como particulares. El banco tenía más de 300 aplicaciones implementadas con diferentes tecnologías, todas ellas en distintas fases. Debido a ello, el banco se enfrentaba a varias dificultades a la hora de interconectar estos sistemas. Algunas de ellas eran
1. Mantenimiento de múltiples sistemas de interfaz: Cada sistema necesitaba sus propias funciones de interfaz para conectar con otros sistemas posteriores. Eso llevó a implementar tipos similares de funciones de interfaz en todos los sistemas.
2. Enorme coste y tiempo para cualquier solicitud de cambio: Como había un cambio en la interfaz del sistema descendente, había que cambiar todas las funciones de interfaz de las aplicaciones afectadas. Estos cambios de interfaz eran caros y requerían plazos de implantación más largos.
3. Dificultades para mantener los documentos de interfaz: Como había muchas aplicaciones, el banco tenía dificultades para mantener los documentos de interfaz de todas ellas.
4. Dificultades en el análisis de impacto: El banco tuvo dificultades para realizar el análisis de impacto de los cambios de interfaz y hubo casos de interrupciones de la producción debido a un análisis de impacto inadecuado.
5. Coste elevado de las licencias: Algunas aplicaciones tenían sus funciones de interfaz desplegadas en middleware específico como JBOSS, lo que supuso costes de licencia adicionales para el banco, aparte del coste relacionado con la aplicación.
Las API pueden ser la respuesta a estos problemas. Una API es un conjunto de reglas que guían a los ordenadores o aplicaciones para comunicarse entre sí. Las API actúan como capa intermedia entre la aplicación y el servidor web, procesando la transferencia de datos entre sistemas2.
Hub de API externa: Esta capa incluye contenedores de API para cada sistema frontend ofrecido por el banco, sus filiales y otras empresas fintech. El propósito de esta capa es implementar los requisitos funcionales del sistema frontend y evitar cualquier lógica en el sistema frontend. Esto también puede denominarse Backend para el sistema Frontend.
Las funciones del hub de API externa incluyen:
Autorización: Autorizar el acceso a la API de cada sistema frontend con Red Hat Single Sign-On.
Agregación: Invocación de múltiples API internas y agregación de resultados para el sistema frontend.
Transformación: Transformación de mensajes de solicitud y respuesta según las necesidades del sistema frontend, como filtros, formateo de datos, conversión de mensajes, etc.
Caché: Servir parámetros o datos estáticos al sistema frontend.
2. Hub de API interno: Esta capa incluye contenedores API para cada procesador de producto o sistemas backend. El propósito de esta capa es servir APIs estándar mediante transformación. Por ejemplo, en el caso de un cajero automático, los mensajes se convierten del formato ISO al formato JSON con fines de estandarización.
Este nuevo diseño de API Hub ayuda al banco con:
Estandarización de las interfaces API: El API Hub garantizó que todas las interfaces API tuvieran formato JSON y que siguieran un diseño API estándar. Esto ayudó a los desarrolladores a comprender fácilmente la especificación y el uso de la API.
Mantenimiento de registros: Las especificaciones de todas las API se consolidaron y se mantuvieron como parte de API Hub y fácilmente disponibles para que todo el mundo pudiera consultarlas.
Reducción del coste de las licencias: Las API se desarrollaron en el marco Apache Camel y se desplegaron como Microservicios en la plataforma de contenedores RH OpenShift. Esto ayudó a reducir el coste de licencia de las instancias individuales de JBOSS necesarias para la función de interfaz de la aplicación.
Análisis de impacto y solicitudes de cambio: De acuerdo con el diseño del concentrador de API, las aplicaciones se conectaron a un sistema (concentrador de API) en lugar de conectarse a varios sistemas descendentes. Por tanto, el análisis de impacto y las solicitudes de cambio se gestionaron sin problemas.
Mejora del rendimiento: El diseño del Hub de API ayudó a reducir el TAT de las funciones frontend, en lugar de invocar múltiples API desde el sistema frontend. Tomemos el ejemplo de la transferencia de fondos: varias validaciones, comprobaciones AML, límites de cuenta y OTP se verificaron mediante llamadas paralelas a la API y, a continuación, se inició la transferencia de fondos. Las llamadas a API paralelas ayudaron a reducir el tiempo de procesamiento de cada actividad.
Conclusión
Los bancos del futuro no se limitarán a satisfacer nuestras necesidades bancarias y de inversión, sino que actuarán como una ventanilla única para todas las necesidades relacionadas con el dinero. Al igual que la nube, una API tampoco es una píldora universal para la transformación digital. Los bancos deben invertir en plataformas nativas de la nube que sean integrales, resistentes al futuro, escalables y ágiles.
Fuentes
1. https://www.fortunebusinessinsights.com/cloud-computing-market-102697
2. https://www.ibm.com/cloud/learn/api
Compartir
