Suite MODHELUS Completa
MODHELUS una Suite     Estratégica para el Negocio     Financiero
 Evolución de las Arquitecturas     Tecnológicas Bancarias
 El Veneer o Fachada
 Procesos de Negocio
 
     
 

La suma de hechos y circunstancias, el reiterado uso del acoplamiento, y la falta de posibilidad para reusar los códigos han llevado a estas arquitecturas a su mayor nivel de ineficiencia. El paradigmático caso del Citibank y la migración de su viejo sistema ¨Cosmos¨ a estas nuevas arquitecturas -con un ahorro operativo de u$s 110 millones anuales- ponen en evidencia las ineficiencias que plantean estas arquitecturas. No sólo son caras, lentas y complejas, sino que entregan una calidad de servicio muy deficiente para el cliente donde sus saldos dependen de la hora y canal al cual se accede. Los diferentes criterios en la interfases al usuario producen ausencia de homogeneidad operativa; la dificultad para una respuesta adecuada en tiempo y forma al mercado, y la necesidad de importantes procesos paralelos, son factores que terminan convirtiendo a la tecnología en una barrera al desarrollo, más que una facilidad estratégica para el negocio bancario.

El nacimiento de las nuevas arquitecturas

Desde el principio de los años ´90, a través de investigaciones y trabajos reflejados en numerosas publicaciones especializadas, se comenzó a vislumbrar la posibilidad de realizar diseños de sistemas que eliminaran el factor de acoplamiento y permitieran el reuso de los códigos dentro de ellos. Los primeros intentos reales se llevaron a cabo entre 1994 y 95, iniciándose fases experimentales entre 1996 y 1997.

El cambio de visión: desacoplamiento y reusabilidad.

El verdadero cambio en los diseños se basa en la visión de la arquitectura, ya no fundamentada en las aplicaciones u operatorias como hasta ese momento, sino focalizada sobre los procesos del negocio.

En el ejemplo ilustrado se describen los procesos de extracción sobre dos operatorias: Cuentas Corrientes y Caja de Ahorros, y se explican sobre dos canales, realizados desde una sucursal y desde un cajero automático. En una arquitectura tradicional esto representaría cuatro programas, que realizan casi las mismas acciones. Difiere en el canal (ya sea sucursal o ATM) y en el impacto final: uno en Cuentas Corrientes o en Caja de Ahorro. Si la visión cambia al proceso, estos son iguales y realizan pasos similares. Es factible entonces construir un código que tenga la particularidad de poseer interfases estándares que le permitan dialogar universalmente y construir servicios.



Así, existe un servicio de canal que es solicitado para cualquier transacción con origen o destino en ese canal, y posteriormente actúan los servicios que permiten llevar adelante la operación solicitada. El servicio se ejecuta y se destruye, no generando relación alguna con algún otro servicio. Eliminando los acoplamientos y el reuso de servicios, posibilita el reuso de los códigos. De esta forma, de requerirse modificaciones, se realizan en un servicio; si se requiere una nueva funcionalidad, sólo debe generarse un nuevo servicio; permite un manejo multicanal simple y sencillo, unifica las plataformas, otorga velocidad a nuevos desarrollos y facilita el mantenimiento y las modificaciones.