Fundada en 1990 por Caja Inmaculada (CAI) y Caixa Sabadell (CES), la Asociación Técnica de Cajas de Ahorros (ATCA) nació con el objetivo de ayudar a sus socios a mejorar el servicio a clientes y reducir costes mediante el desarrollo de servicios compartidos, principalmente en el ámbito de las TIC.
Constituida en Agrupación de Interés Económico (AIE) en 1992, ATCA cuenta a día de hoy con un capital social de 6,9 millones distribuido entre sus cuatro socios: CAI y CES, ambas con un 31 por ciento; Caja Rioja, que entró a formar parte de la agrupación en 1992 y cuenta con una participación del 13 por ciento; y Caja Insular de Ahorros Canarias (CIAC), La Caja de Canarias, que se incorporó en 1998 y controla el 25 por ciento.
El nacimiento de ATCA coincide con un proyecto de renovación integral de los sistemas de sus asociadas, inicialmente CAI y CES, que venían operando en sistemas Bull, y a las que, posteriormente, se sumó Caja Rioja, que trabajaba con sistemas NCR.
“El objetivo era poner a disposición de las entidades una plataforma tecnológica compartida con el objetivo de aumentar las prestaciones, mejorar el servicio y minimizar los costes de explotación”, indica Pablo Serrats, director de Desarrollo de ATCA.
En ese momento, se lleva a cabo una renovación total de las aplicaciones de core bancario y terminal financiero, apostando por la plataforma CIS-DB2, para lo que se firma un contrato con IBM que, a su vez, confía el desarrollo a Andersen Consulting (ahora Accenture).
Como detalla Serrats, “el desarrollo empezó en 1992 y en 1994 entran en explotación las primeras aplicaciones para finalizar la migración total de las cajas en 1998 con el arranque de las últimas en CIAC”. Con la puesta en marcha de las primeras aplicaciones se empieza a montar la estructura propia de personal en ATCA, que hoy cuenta con 173 empleados.
La infraestructura de soporte al nuevo aplicativo bancario, alojada en el CPD de ATCA en Zaragoza, se basó en un primer momento en sistemas mainframe IBM 9021 con una capacidad de 120 MIPS que, a día de hoy, han evolucionado a dos IBM zSeries 990 sumando 1.044 MIPS.
Para el desarrollo del nuevo terminal financiero, que corría sobre OS/2, se utilizó la plataforma CT2 del Gigante Azul en un entorno que exigía distintos sistemas middleware en base a una arquitectura cliente/servidor.
Finalizado este macroproyecto y tras llevar a cabo las necesarias adaptaciones asociadas al efecto 2000 y la adopción del euro, ATCA se planteó un nuevo proyecto de mejora de la calidad de los procesos con el objetivo final de “elevar la calidad de los productos entregados, reducir los costes, incrementar la satisfacción del usuario y mejorar la calidad de las estimaciones de costes, proyectos, etc.”, explica Serrats.
Con esa visión, ATCA apostó por el Modelo de Capacidad y Madurez (CMM), ahora CCMI, y emprendió un viaje que le ha llevado a la obtención del Nivel 5, la máxima certificación en CCMI/SW/SE (Modelo de Madurez de Capacidad Integrada para Software e Ingeniería de Sistemas), convirtiéndose en la tercera empresa española tras Capgemini y Coritel- que lo consigue. ATCA inició la adopción del modelo en 2002 de la mano del
ESI (European Software Institute).
“Nos costó dos años alcanzar el Nivel 2 y posteriormente hemos ido subiendo un nivel cada año”, indica Serrats. El viaje ha supuesto la mejora de los procesos de desarrollo y mantenimiento de aplicaciones en la organización que, asimismo, ha desarrollado distintas herramientas internas de apoyo, incluyendo el denominado Sistema de Gestión de Actividades (SGA), una aplicación que “permite gestionar el ciclo de vida completo de los trabajos”, señala Serrats, para llamar la atención sobre avances clave como “el inventario de todas las solicitudes de trabajo de las cuatro cajas, la estimación precisa de costes, la planificación y el seguimiento exhaustivo de las incidencias, etc. además de la generación periódica de una gran cantidad de métricas de servicio”.
La adopción de las buenas prácticas del modelo CCMI ha corrido de forma simultánea al desarrollo de otros importantes proyectos y, de hecho, ha supuesto un apoyo fundamental en el salto de la organización a nuevos entornos abiertos, con el que justamente se busca eliminar las dependencias que, en buena medida, lo provocaron. Y es que, como explica Serrats, “hacia 1999, IBM nos comunica la descatalogación de OS/2, al que finalmente dio cierta continuidad porque había muchas entidades financieras que tenían su plataforma ofimática de oficinas en OS/2; así como de la herramienta CT/2 que, como había tenido poca implantación, estaba sentenciada”.
En esa tesitura, ATCA vuelve a plantearse el desarrollo completo de un nuevo terminal financiero. El proyecto, que implicaba el desarrollo de 4.500 transacciones, supuso un avance notable en la misma concepción de la
operativa de los sistemas bancarios. “Nuestro objetivo era prescindir del middleware, de forma que para instalar el terminal sólo fuera necesario un sistema operativo que soportara la máquina virtual, reduciendo notablemente los costes de software”, explica Serrats.
Con estas premisas, ATCA abordó el desarrollo de un nuevo Terminal financiero (NFT) en Java con Apache Tomcat como servidor de aplicaciones que, en septiembre de 2001, se implanta en Caixa Sabadell y posteriormente en el resto de las cajas socias, que migraron de OS/2 a Windows. No obstante “la aplicación es multiplataforma y, de hecho, internamente la hacemos correr en Linux”, apunta el director de Producción y Sistemas de ATCA, Fernando Cruas, abriendo la puerta a Linux en el entorno cliente de las cajas.
No en vano, el software libre es uno de las principales líneas de avance de ATCA, como demuestra su plataforma de puesto de trabajo Atux (de ATca y tUX). “Se trata de una distribución Linux construida a partir de Debian Sarge que corre sobre Red Hat. Actualmente estamos desarrollando una distribución en Ubuntu”, señala Cruas.
A día de hoy, Atux ya se está probando con vistas a su implantación en las oficinas, si bien existen algunos obstáculos. “Aún no existen drivers para periféricos como los recicladores o los cajeros”, argumenta el mismo técnico.
El desarrollo del nuevo terminal financiero no sólo supuso un éxito para ATCA, también permitió a la organización ganar experiencia en Java, en línea con su apuesta por el desarrollo interno. “Creamos arquitecturas propias de desarrollo de transacciones que resuelven los requerimientos de conectividad y comunicación con el host mediante sockets TCP/IP”, explica Cruas. También se desarrolló una herramienta IDE basada en Netbeans para pintar pantallas, facilitando el trabajo de los desarrolladores que venían trabajando en Cobol y, de esta forma, “sólo tienen que embeber la lógica del código”, apunta.
Esta etapa fue crucial teniendo en cuenta que ATCA abordaba, en paralelo, el desarrollo de la plataforma de banca electrónica para sus socios, un campo en el que también se decanta por el software libre. “Utilizamos JSPs para el desarrollo y Apache Tomcat como servidor de aplicaciones”, indica Cruas. Inicialmente en este entorno se utilizaron máquinas Sun/Solaris, pero con el tiempo se ha estandarizado en Intel ya que el desarrollo de una prueba piloto de la banca electrónica sobre RedHat con Intel puso de manifiesto que “si no superior, el rendimiento era igual que el de las máquinas Solaris que, en aquel momento, eran bastante caras”, añade Cruas.
Así y tras el uso de una plataforma formada por Pentium III clónicos, hace alrededor de uno año se adquirieron un total de cuatro servidores IBM x306 con Pentium IV que aportan la potencia necesaria para soportar un entorno que actualmente registra alrededor de 8,5 millones de operaciones mensuales con hasta 2.000 clientes concurrentes. “Hemos demostrado que con máquinas de bajo coste, Linux proporciona una tremenda estabilidad gracias a una infraestructura de aplicación robusta que transfiere a la plataforma la estabilidad y alta disponibilidad propias de un host”, destaca Serrats.
La apuesta por Linux también ha alcanzado a los sistemas medios en ATCA que hoy cuenta con alrededor de 80 servidores Linux y 20 servidores Windows en producción. En este campo, ATCA emplea Red Hat Entreprise 4 para soportar los firewall StoneGate de StoneSoft- y otros elementos de seguridad, como los sistemas BlueCoat antivirus y de detección de intrusiones.
Estos sistemas medios, así como el host central, se encuentran el mencionado CDP de ATCA en Zaragoza, que tenía un respaldo en frío con IBM desde 1997 y en 2003 se conectó con una línea de 1 Gb-Ethernet a una sala externalizada en la sede madrileña de IBM en Santa Hortensia.
Los procesos de back up descansan en cabinas de HDS, a las que se suma un robot de cintas IBM. En la actualidad y como explica Cruas, “estamos renovando los sistemas de disco y las comunicaciones, de forma que vamos a contar con dos líneas de 2 Gb una de 400 kilómetros y otra de 800 kilómetros- por caminos distintos- que IBM ha contratado a Telefónica”. El escenario de comunicaciones en ATCA, que emplea routers de Cisco, se completa con las líneas de conexión con las cajas, que suman 890 oficinas y 5.058 terminales.
“Tenemos tres ATM a 4 Mbps de Zaragoza a Logroño, Sabadell y Las Palmas, tres ATM con igual caudal desde Madrid a las mismas localizaciones y una línea ADSL a 2 Mbps con Las Palmas, todas ellas de Telefónica”, indica Cruas, para apostillar que “en caso de caída de uno de los ATM, automáticamente todas las oficinas entran por Zaragoza o Madrid”.
Por su parte, el sistema autónomo de Internet se conecta con dos enlaces MacroLAN Ethernet a 16 Mbps en Zaragoza (Telefónica) y Madrid (BT) y una Frame Relay a 2 Mbps de IBM en Madrid. Asimismo, ATCA emplea FrameRelay y circuitos x25 para conectar con otras entidades como CECA, Sermepa o las notarias, y para el uso de Editran.
Con toda esta experiencia acumulada, ATCA abordó su proyecto estrella de desarrollo de un core bancario que, primero denominó Nueva Arquitectura Finacierra (NAF) y luego rebautizó como Abaco (Arquitectura Bancaria Abierta Corporativa). “La idea de esta arquitectura era desarrollar un gestor de teleproceso, como es el CIS, que resolviera las transacciones; así como una arquitectura de desarrollo que facilitará el trabajo de los desarrolladores, que venían trabajando en Cobol cuando nuestra apuesta se concreta en Java a fin de ser independientes de las máquinas”, explica Serrats.
ATCA ha migrado a la nueva plataforma Abaco las aplicaciones de más uso en base a una arquitectura en tres capas: una capa de lógica de la presentación que reside en los terminales de oficinas y el servidor de banca por Internet-, una capa de lógica de negocio que, soportada por la granja de servidores Linux, desempeña funciones como el acceso y actualización de los datos, la seguridad o el formateo de mensajes; y una capa de datos que, por el momento, se mantienen en el gestor DB2 sobre la antigua plataforma mainframe, si bien parte de ellosse van moviendo a un cluster Linux con DB2 o a SQL.
Gracias a Abaco, que accede a DB2 a través del conector DB2- Connect, ATCA permanece desde 2002 con la potencia del host congelada, mientras que en el mismo periodo ha registrado un incremento de sus operaciones del 11 por ciento. Y es que uno de sus objetivos era justamente “no incrementar la capacidad en MIPS del host, con el gasto adicional que implica en coste de licencias”, indica Serrats.
El directivo destaca que “los alrededor de 1,3 millones de euros que hemos invertido en Abaco se han amortizado en dos años”. En Abaco se han incluido transacciones relativamente sencillas que suponen un número elevado de operaciones. “En este momento y considerando únicamente el terminal financieros, el 40 por ciento de las operaciones se procesan en Abaco, y teniendo en cuenta el total incluyendo cajeros y banca electrónica- el porcentaje se sitúa en el 25 por ciento, es decir, 14 millones de operaciones de un total de 56”, subraya Serrats.
Merece destacarse que la plataforma en la que se apoya Abaco, formada por ocho servidores IBM xSeries 306 corriendo Red Hat, funciona como un grid computing para la realización de procesos batch. En esa línea Serrats indica que “estamos desarrollando un gestor de eventos para cambiar el paradigma y resolver un batch masivo en máquinas pequeñas mediante un sistema de distribución de trabajos o pequeños procesos”.
