El reto de los banqueros con el uso de la tecnología

El reto de los banqueros con el uso de la tecnología

Los avances tecnológicos como el procesamiento en la nube, han permitido revoluciones como las de “Big Data” o “Blockchain”. Imagen de Gerd Altmann en Pixabay


La implementación de la tecnología y todos sus procesos cada vez trae grandes retos para los banqueros, específicamente aquellos de las áreas funcionales o de negocio, por ejemplo, cuando se encuentran con obstáculos tecnológicos, sobrecostos descomunales y tiempos de entrega que no cumplen con las expectativas esperadas.

Si bien es cierto que la tecnología ha venido avanzando a una velocidad impresionante y se supone que el agilismo es la nueva norma, hay señales, en nuestras organizaciones de servicios financieros, que nos deberían advertir sobre expectativas posiblemente desproporcionadas con relación a la verdadera capacidad de responder con proyectos rápidos y de bajo costo.

La industria de servicios financieros es de las primeras industrias en invertir muy fuertemente en tecnología desde hace más de 50 años. Esto hizo que muchos de los grandes bancos de la actualidad crecieran y se expandieran de manera exponencial. Esta misma historia, es la que hace que las complejidades tecnológicas de estas organizaciones se hayan acumulado en el tiempo creando sistemas basados en multiplicidad de arquitecturas, lenguajes de programación y estructuras de datos donde lo que terminamos obteniendo son unos “Frankenstein” muy difíciles de descomponer, modificar o sustituir.

Por esta misma razón, vemos que bancos digitales, bancos más recientes o bancos más pequeños, parecen tener un problema mucho más manejable que los bancos grandes y de mayor tradición (y la relación no es lineal sino exponencial).

El mejor ejemplo de estas complejidades son los cambios de core. En muchas organizaciones, cambiar el core es como cambiarle el motor a un auto en movimiento. Vemos que una implementación de un nuevo core en un banco digital se puede lograr en semanas y costos cercanos a las centenas de miles de dólares, mientras que el reemplazo de un core bancario de un banco grande y tradicional, podría tomar varios años y varias decenas de millones de dólares (y en casos extremos a centenas de millones de dólares).

Para ayudar a darle contexto al banquero de negocio para que evalúen un proyecto en particular y puedan “preveer” los potenciales problemas, vamos a intentar simplificar las 3 preguntas que se deberían hacer. Cabe notar que, en pro de hacer estas preguntas orientadas al área de negocio, estamos sobre simplificando y dejando de lado muchos temas que los tecnólogos podrían considerar errados o incompletos.

Cómo diagnosticar las complejidades tecnológicas:

1.- ¿Cómo y dónde se encuentran los datos?

Aquí hay dos consideraciones que se deben hacer. La primera es que a medida que venimos manejando datos desde hace más tiempo, la naturaleza de estos datos es hacerse obsoleta, incompleta e inconsistente. Así que entendiendo desde cuándo la organización maneja un tipo de información, de manera natural podemos prever que vamos a tener dificultades.

La segunda es de índole tecnológico. Me atrevería a decir que la forma en que se almacena y se procesa la información es de las cosas que más han cambiado desde los años 70 cuando se crearon las primeras bases de datos relacionales. Cualquier base de datos que esté basadas en tecnologías puramente relacional o de generaciones anteriores como redes o jerárquicas están destinadas a pasar por un proceso más doloroso para ser consultadas, procesadas o migradas.

Los avances tecnológicos en base de datos no estructuradas, base de datos en memoria y procesamiento en la nube, han permitido revoluciones como las de “Big Data” o “Blockchain” que radicalmente cambian la velocidad y el potencial de la utilización de los datos.

2.- ¿En qué arquitectura y lenguaje de programación están los legados?

He visto casos donde una célula ágil es capaz de producir una aplicación móvil con mucha funcionalidad y una extraordinaria experiencia de usuario en tan solo semanas y, por otro lado, nos quejamos de la gente de tecnología que le pedimos un “simple” ajuste en la fórmula de cálculo de un producto crediticio y llevamos meses esperando los resultados.

Una de las razones por la que encontramos estas diferencias tan marcadas no es sólo por la aplicación de nuevas metodologías como el agilismo (que efectivamente acerca a los usuarios con los tecnólogos y contribuye a un resultado más rápido y cercano a lo que el usuario espera), sino también, la evolución en los lenguajes y paradigmas de programación representa otra de las principales razones para obtener diferencias tan marcadas en los resultados.

Se tienen identificadas 5 generaciones de lenguajes de programación, y cada generación ha venido simplificando y reduciendo las distancias entre el lenguaje técnico y el lenguaje natural. Las últimas generaciones hablan de “low-code” o “no-code” donde se intenta que la programación sea más un conjunto de instrucciones en lenguaje natural o gráfico que es perfectamente interpretado por las aplicaciones, reduciendo drásticamente los tiempos y complejidades.

Con relación a la arquitectura, hay que preguntarse si el sistema es una gran aplicación “monolítica” corriendo en un mismo ambiente o si es una aplicación “compuesta” por múltiples aplicaciones (módulos, servicios, micro-servicios, etc). Los desarrollos legados y obsoletos normalmente están construidos como una gran super-aplicación con miles de líneas de código donde todo está relacionado internamente. Estas aplicaciones han pasado por la mano de miles de programadores y seguramente la documentación deja mucho que desear. Cualquier modificación sobre estos grandes “monolitos” se convierte en una suerte de ensayo y error para entender cómo modificarla y las consecuencias de esta modificación sobre el resto del código.

En la medida que nuestra arquitectura esté más descompuesta, se hace más sencillo el mantenimiento y el entendimiento de cómo cada servicio se relaciona con el resto de los componentes.

3.- ¿Qué tanto hay que integrar?

Un banquero de negocio una vez me mostró una aplicación móvil extraordinaria que habían desarrollado en sólo 3 meses, pero esta aplicación no estaba todavía en producción porque sólo faltaba que tecnología la “conectara” con el resto de los sistemas del banco. Llevaba más de 10 meses esperando esta integración.

Hay que tener en cuenta que las aplicaciones del pasado no fueron pensadas para conversar con ninguna otra aplicación, lo que es menos cierto en desarrollos más recientes donde ya pensamos en nuestras aplicaciones con sus APIs (Application Platform Interfase) y la forma de integrarse ha pasado a ser bastante estándar.

Hacer que estas aplicaciones del pasado expongan su funcionalidad o reciban instrucciones de otras aplicaciones tiene un reto que crece exponencialmente en función a la obsolescencia de las arquitecturas y las estructuras de datos.

Con sólo preguntar qué tanta integración requiere un proyecto, con cuántas aplicaciones debe integrarse y el nivel de obsolescencia de estas aplicaciones, se puede tener un “proxy” de las dificultades que tenemos en frente.

En resumen, le diría al banquero de negocio al encontrarse frente a un reto tecnológico, que pregunten por estas tres dimensiones: ¿cómo se encuentran los datos?, ¿cómo es la arquitectura de los legados? Y ¿qué tanto hay que integrar con otras aplicaciones?

Por supuesto, hay muchas otras dimensiones que afectan las complejidades de un desarrollo tecnológico: temas metodológicos, cantidad de usuarios, resistencia cultural, estructura organizacional, procesos y operaciones, etc. Pero muchos de estos elementos son de más fácil entendimiento para el banquero de negocio. Con estas tres preguntas, intentamos reducir la frustración y la mala comunicación que es tan común entre las áreas de negocio y tecnología.

La solución en el largo plazo es la renovación de las tecnologías, pero esto toma tiempo y mucha inversión. Esta renovación puede venir en forma de reemplazo completo de soluciones tecnológicas, pero también es posible hoy en día pensar en re-arquitecturas y otros mecanismos más evolutivos de renovación.

Miguel  Caldentey

Socio de E, líder de Consultoría Tecnológica para Centroamérica y el Caribe
- Leer más artículos de este autor -