Historia de las arquitecturas bancarias
MODHELUS es una “nueva generación de arquitecturas tecnológicas bancarias” que superan y eliminan los grandes problemas que -hasta hoy- han constituido una barrera al desarrollo del negocio bancario.
Las mayores deficiencias que platean las arquitecturas tradicionales residen en el factor de acoplamiento y la no reusabilidad del código. Analicemos brevemente cómo se generan y cuál es su impacto en los sistemas bancarios.
El nacimiento de las arquitecturas
Las operatorias bancarias nacieron como aplicaciones separadas que resolvían una operatoria en particular. El objetivo estaba puesto en poder procesar masivamente las cuentas y obtener un reflejo y control contable de las mismas. Sin duda, este objetivo fue alcanzado y permitió una fuerte expansión de la banca minorista. El resultado fue lo que hoy es conocido como estructura en “silos”, donde cada silo resuelve una operatoria y sus cuentas asociadas a ella.
La necesidad de relacionar las operatorias
La propia expansión de la banca trajo como consecuencia la necesidad de relacionar las cuentas con los clientes, tal es el caso del débito automático, el servicio de comercio exterior, la aparición de la tarjeta de crédito, etc.
La aparición del factor de acoplamiento
Es a partir de esta necesidad de relacionamiento que hace su aparición el factor de acoplamiento, uno de los más significativos elementos que han conspirado contra la eficiencia y eficacia de los sistemas bancarios. El factor de acoplamiento se produce cuando es necesario relacionar aplicaciones aisladas. Para sincronizarlas y poder intercambiar información entre ellas, deben desarrollarse dos interfases que convierten y compatibilizan datos en ambas aplicaciones, más el natural control del flujo de comunicación entre esas aplicaciones. Este factor tiene un comportamiento exponencial. Analicemos brevemente el comportamiento de este factor. Relacionar 2 aplicaciones requiere de tres programas distintos: dos interfases, y un programa de control. Asumamos que el programa de control puede ser el mismo en cada unión de aplicaciones y que, una vez desarrollado, sólo se requieren dos programas para cada interrelación. Para 3 aplicaciones se han de requerir 6 interfases; para 4 aplicaciones 12 programas; para 5 aplicaciones 20; y para N= N x (N-1).
Si ahora deseamos generar una nueva aplicación, debemos entonces programarla y desarrollar las interfases que le permitan relacionarlas con las restantes. Aquí se observa una ecuación donde N = 2 x N. De esta forma, para relacionarla con cuatro aplicaciones se han de requerir 8 programas.
El acoplamiento encarece, lentifica y complica el desarrollo
Resulta evidente que, a mayor cantidad de aplicaciones y funcionalidades que se van incorporando al sistema, más complejo, caro y lento de desarrollar se torna, sin contar con las modificaciones que el mercado obliga a realizar y que significan retocar -no sólo aquello que motiva la modificación-, sino todas las relaciones que esa parte mantiene con el resto. Aquí debe también sumarse la necesidad de testear todas las aplicaciones relacionadas para evitar la propagación de inconsistencias que suelen producirse cuando se modifica un acople. Las modificaciones se convierten en regueros de pólvora, se sabe cuando comienzan pero no dónde terminan.
El tiempo real y la reusabilidad
La aparición de lo que ha dado en llamarse “el cambio en los espacios del negocio” -en los albores del año 1995, que se tradujo en la explosión de los canales alternativos de distribución bancaria- produjo un sensible impacto sobre las arquitecturas, lo cual obligó a replantearlas.
La reacción tecnológica a los canales alternativos fue la generación de una capa de servidores con capacidad para operar 7 x 24, de manera de poder atender la demanda continua que distinguen a estos canales cuando el sistema Legacy está en procesos de consolidación, normalmente en horario nocturno. La necesidad de operar en forma independiente de los Legacy obliga a dotar a esta capa, y a cada canal, de todas las funcionalidades necesarias. Esto produce una explosión de múltiples programas que realizan idénticas funcionalidades para cada canal, además de obligar al procesamiento en paralelo para sincronizar las diferentes bases que quedan operativas cuando el Legacy sale de operación.
Las modificaciones funcionales exigen ahora no sólo la modificación y testeo de los programas centrales y sus interfases de acoplamiento, sino también el de todos y cada uno de los canales que poseen esta funcionalidad. Igualmente ocurre con nuevos productos o procesos. La falta de la posibilidad de reuso de las funcionalidades produce esta multiplicidad de programas diferentes que realizan la misma función. La suma de factores produce lentitud, encarecimiento y complejidad.
La suma del factor de acoplamiento y la multiplicidad de programas ha generado un incremento constante de los costos tecnológicos, sensibles demoras en la capacidad de reacción ante nuevas demandas del mercado, y una muy lenta adecuación a las necesidades de nuevos procesos de negocio.
Un impacto adicional de estas arquitecturas es la disminución de la calidad de servicio y la confiabilidad en relación al cliente, al poseer necesariamente diferentes saldos, según la hora y canal donde el cliente realice la consulta.
Este fenómeno progresivo de inadecuación de las arquitecturas tecnológicas ha convertido, en 20 años, a aquel maravilloso motor impulsor de la banca -que significó la introducción de la tecnología en el negocio- en su mayor barrera y limitación para la expansión y competitividad.
Por todos estos motivos, es necesario MODHELUS.
MODHELUS “una nueva generación de soluciones para el negocio financiero”
