¿Qué es MODHELUS?

Se trata de 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.

Evolución de estas arquitecturas:

1) Cómo nacen y se desarrollan
2) El ácido corrosivo del acoplamiento
3) La Babel de los canales alternativos
4) Por qué SOA y el drama de la redundancia


1) Cómo nacen y se desarrollan

Los sistemas bancarios nacieron para resolver las operatorias bancarias masivas y así reflejar esas operatorias en la contabilidad. De esta forma, se diseña y construye un sistema de cuentas corrientes, luego otro para la caja de ahorro, otro para plazo fijo y así siguiendo. Esto fue configurado como arquitectura en “silos”, ya que cada subsistema está aislado, desarrollado en forma independiente y no prevé el relacionamiento entre sí.

Arquitectura en Silos

Este tipo de informatización -aún cuando hoy se la considera, y con razón, obsoleta- permitió la expansión de la banca minorista, por su capacidad para manejar grandes volúmenes con alta precisión y seguridad, e hizo factible la administración contable de grandes volúmenes de clientes. Pero este mismo crecimiento de la banca minorista generó competencia y devino en la necesidad de generar nuevos servicios y facilidades a fin de atraer y retener a los clientes. Veamos un ejemplo que grafica la problemática de la generación de nuevos servicios en estas estructuras: la aparición del servicio de Débito Automático. Este servicio necesita relacionar aplicaciones en las cuales se hallen los saldos positivos sobre los cuales deben debitarse los servicios. Esto exige relacionar este nuevo servicio con, al menos, la aplicación que administra a las cuentas corrientes, las cajas de ahorros y las tarjetas de crédito, todas cuentas que el banco debe ofrecer al cliente para que sobre ellas se realicen sus débitos.




2) El ácido corrosivo del acoplamiento

Nace así uno de los factores más negativos en la explotación de los servicios financieros, el cual ha dado en llamarse “acoplamiento” y se origina por el relacionamiento de dos estructuras de aplicaciones aisladas. El relacionamiento de dos estructuras independientes requiere, al menos, de interfases que normalicen datos y registros de ambos lados con el fin de poder intercambiarlos, y una aplicación que controle el flujo de comunicación entre las aplicaciones. Este fenómeno es conocido como “acoplamiento”. Véase la regla de factor A = N x (N-1), donde N es la cantidad de aplicaciones a relacionar. Analicemos el caso del relacionamiento de 4 aplicaciones en una estructura en “silos”. Para N = 4 es N-1 = 3, lo que hace que las interfases necesarias sean 12, tal como se aprecia en el gráfico.

Para relacionar 4 aplicaciones se requieren 12 interfases. N x (N-1). Este factor de acoplamiento se ve agravado si se requiere crear una aplicación nueva que mantenga las relaciones existentes. En este caso, se ha de requerir la programación de 2 interfases nuevas. Para el caso ejemplificado, una nueva aplicación requerirá de la programación de 8 interfases nuevas, además la propia aplicación en sí misma. Con posterioridad, cualquier modificación en algunas de las aplicaciones obligará a rever y modificar las interfases y aún las propias aplicaciones, con el necesario testeo del conjunto. Este fenómeno de propagación del acoplamiento ante modificación lentifica fuertemente los desarrollos. La arquitectura exige una alto costo para su modificación, testeo y su mantenimiento.



La función resultante de este factor de acoplamiento es del tipo exponencial. Resulta evidente entonces que cuantas mayores sean las funcionalidades y facilidades que se le requieran a este tipo de arquitecturas, mayor será la complejidad de interfases, menor su eficiencia, mayores tiempos de programación, más dificultad para su mantenimiento y modificación, y ha de exigir más tareas de control y testeo cada vez que se realiza una modificación. Esto se traduce en costos ciertos en recursos y tiempos e imponderables en pérdidas de oportunidades frente al mercado. Este fenómeno del acoplamiento termina generando fuerte retardos en el lanzamiento de nuevos servicios, resta competitividad a la banca y aumenta fuertemente los costos de desarrollo y mantenimiento. A partir de los años ´90 se introdujo el diseño en capas funcionales unidas por interfases estándares que permitió -en aquellos bancos que incorporaron este tipo de arquitecturas- atenuar el acoplamiento y disminuir el fenómeno de la propagación de las modificaciones y el mantenimiento.




3) La Babel de los canales alternativos

Pese a esta atenuación del efecto de acoplamiento, es a partir de 1995 que la banca enfrenta su último gran desafío. El crecimiento y la demanda sostenida de los canales alternativos de distribución (e-banking, phone-banking, redes de autoservicio, kioscos, call-centers, etc.) enfrentó a las instituciones cuyas estructuras tecnológicas se basaban en las sucursales, tradicional y único canal de distribución previsto en estos sistemas. Las estructuras tecnológicas bancarias fueron diseñadas y configuradas para una operación de 9 horas al día y 5 días a la semana, lo cual resultaba suficiente para administrar sus operaciones centrales y atender su único canal de distribución. La limitación operativa de una estructura 9 x 5 fue evidente cuando se produjo la introducción del primer canal 7 x 24 con la incorporación al mercado de los cajeros automáticos.
Esta problemática se resolvió haciendo empresas independientes de los bancos que manejaban y administraban las redes de cajeros, y que transmitían posteriormente las novedades sobre movimientos para la consolidación de saldos en el banco (caso Banelco, Red Link, Red Banc, Bancomat, Cirrus, etc.). Esta típica configuración de los sistemas bancarios (Esquema 1) terminó de demostrar su incapacidad con la aparición de los nuevos canales alternativos que plantean necesidades operativas de 24 horas durante 7 días de la semana, y además exigen satisfacer al cliente dónde, cuándo y cómo a él le resulte conveniente.



Esto plantea cambios en las estructuras tecnológicas que permitan una continuidad operativa para la cual las arquitecturas implementadas no otorgan respuestas. También se requiere -en la estrategia de la distribución de servicios- un acabado conocimiento de los usos y costumbres de los clientes con el fin de optimizar las inversiones en cada canal, lo que necesita una estructura de información no prevista en los diseños tradicionales. Estas inadecuaciones de las arquitecturas y estructuras no le han permitido a la banca aprovechar el natural abatimiento de los costos transaccionales que representa el uso de canales alternativos incrementando sensiblemente la tasa de transferencia de transacciones manuales a las de autoservicio; ni implementar una estrategia de sustitución de activos, cada día más necesaria en la pelea por la reducción de costos. A estos factores se unen las deficiencias en la calidad de los servicios requeridos por los clientes, en términos de ubicuidad, tiempo, consistencia, homogeneidad y seguridad. Esta exigencia de “banca en tiempo real”, claramente visible a partir de la segunda mitad de los años `90, agudiza los problemas y la deficiencia arquitectónica que vienen arrastrando los sistemas centrales instalados en la banca. Frente a estos nuevos requerimientos, nos encontramos con arquitecturas creadas para operación 9 horas x 5 días, generadas como aplicaciones separadas, no relacionadas entre sí, no orientadas al negocio, lentas para reaccionar, y caras de mantener y modificar.




4) Por qué SOA y el drama de la redundancia

La necesidad de manejar múltiples canales potencia fuertemente las deficiencias anotadas y plantea como indispensable el poder reusar los códigos generados. Bajo el concepto de estructura tradicional, cada canal ha de tener todas las funcionalidades que le permitan operarlo. Analicemos el programa para “obtener el saldo de cuenta del cliente”. Esta función o servicio estará repetida en la aplicación que atiende a los cajeros automáticos, a los puestos de autoservicio en sucursal, al autorizador de tarjetas de crédito, a los sistemas de cuentas corrientes, a la caja de ahorro para atención de la caja en sucursal, etc., aún cuando el saldo sea uno sólo y se encuentre en la misma base de datos. Si el banco desea desarrollar una aplicación de home-banking, entonces deberá programar una vez más la función de requerimiento del servicio “obtener saldo de cuenta” en su aplicación de home-banking. Lo que produce una explosión de los canales alternativos es una multiplicación de códigos que hacen lo mismo, tantas veces como canales de distribución existan. Es muy probable que los códigos tengan lógicas, lenguajes y tecnologías diferentes, todo lo cual aumenta las líneas de códigos a mantener, y la necesidad de diferentes especialistas y de documentar tantas veces como el servicio esté repetido. Esto se muestra como un factor especialmente crítico y de agravamiento de los costos tecnológicos y del deterioro del servicio. Se ha evidenciado de igual manera la necesidad, en un primer enfoque, de poseer códigos reusables que evitaran tener que programar cada vez funciones lógicas iguales para administrar cada uno de los diferentes canales. La nueva arquitectura SOA, mencionada ya en papeles de trabajo de investigadores de laboratorio a principio de los años ´90, no sólo ha aportado la posibilidad de diseñar arquitectura con códigos reusables, sino que instauró además el concepto de servicio a los procesos o aplicaciones. Así, una obtención de saldo es en esta arquitectura una caja negra que posee interfases estándares que le permite comunicarse con cualquier aplicación que requiera este servicio. Con esta arquitectura no existe diferencia ni de lógica, ni de código entre el requerimiento de un saldo desde un cajero automático o desde home-banking, excepto a su inicio donde lo que se diferencia es la lógica del dispositivo que invoca el servicio, que a su vez es la misma siempre que se usa ese dispositivo, sin importar el servicio que se invoque. Este nivel de granularidad y estandarización de las aplicaciones posee características únicas en sus beneficios y facilidades, entre otras:

La modificación de un servicio es la simple modificación del código de una caja negra y su testeo. La necesidad de nuevos servicios o funcionalidades es la generación de una nueva caja negra y su testeo. Al no poseer ni conservar estados en los servicios, no se requieren sincronismos ni acoplamientos. Un work-flow administra la secuencia de los servicios para constituir los procesos. Modificar un proceso es simplemente modificar el work-flow y testearlo.
  
Surge claramente que en esta arquitectura:

La velocidad de desarrollo y modificación es más rápida y sencilla. El esfuerzo de desarrollo es mucho menor. La ausencia de acoplamiento y asincronía permite el procesamiento clisterizado de acuerdo con las necesidades y volúmenes. Se unifican plataformas y tecnologías, y se abaten sensiblemente los costos de explotación, haciendo más competitiva a la institución financiera.

Por todas estas razones, MODHELUS es una “nueva generación de sistemas bancarios”.