miércoles, 13 de febrero de 2008

Historia de la evolución del Hypatia - Sistema Financiero Contable

Antecedentes
Hace 12 años (1996), y por encargo de la Asociación de Cajas Rurales, se inició el proyecto de desarrollo del Sistema de Información Financiero Contable de Cajas Rurales denominado en forma abreviada Siscarul (Sistema de Cajas Rurales). La empresa GMD (Graña & Montero Digital) fue la empresa seleccionada para llevar adelante dicho proyecto.

Durante la etapa previa al inicio del proyecto el equipo técnico de la Asociación seleccionó el entorno de desarrollo IDE y el sistema gestor de base de datos o DBMS a ser usado. Se eligió como herramienta de desarrollo al PowerBuilder® y como sistema gestor de base de datos (motor de base de datos) al Anywhere®, ambos productos de la corporación internacional Sybase®.

Consideramos que esta elección fue acertada ya que el PowerBuilder es una herramienta que permite un ciclo de desarrollo de productos más rápido comparado con otras herramientas similares, y el Anywhere (Adaptive Server Anywhere o ASA) porque se requería de un motor pequeño (fácil de administrar y mantener), relativamente barato y con capacidad de escalar a otro de mayor envergadura y con mayores prestaciones cuando las circunstancias así lo requieran.

Luego de una serie de problemas sobretodo de índole administrativo que surgieron durante el proceso de desarrollo, el proyecto se culminó a mediados del año 1998 y posteriormente fue implantado en las siguientes Cajas Rurales: NorPeru (año 1998), Sipan (año 1999), Sr. de Luren (2000), Los Libertadores (año 2001) y Cajamarca (año 2002). La implantación en la Caja NorPerú la realizó la empresa GMD y posteriormente el mismo sistema fue implantado en las demás Cajas por terceros con el nombre de Hypatia. La implantación en las Cajas Sipan, Sr. de Luren y Los Libertadores fue realizada por un equipo técnico conformado en la Asociación y se tomó en promedio 1 año en cada una. La implantación en la Caja Cajamarca fue realizada por una empresa independiente y se tomó aproximadamente 3 meses.

A mediados del año 1999 (un año después de haber sido implantado) se inicia la primera adecuación del sistema de información Hypatia. La Caja NorPerú convoca a nuestra empresa http-peru para realizar la adecuación del módulo de contabilidad de su sistema de información al nuevo plan de cuentas especificado por la SBS. La estrategia que se siguió para tal efecto fue rediseñar completamente dicho módulo y convertirlo en una aplicación independiente del Hypatia con el objetivo de no solo ajustarlo a las especificaciones dadas por la SBS sino sobretodo de mejorar su performance. Este proyecto culminó exitosamente dentro del presupuesto y del cronograma especificados previamente y con la completa satisfacción de los usuarios de su área de contabilidad.

Esquema de base de datos centralizado

En el año 2001 la Caja NorPerú nos encarga realizar la segunda adecuación a su sistema de información: rediseñar su sistema para que trabaje bajo un esquema de base de datos centralizado, esto es que las agencias remotas accedan a una misma base de datos centralizada. Es importante señalar que originalmente el Hypatia se había diseñado para que trabaje bajo un esquema cliente/servidor clásico existiendo en cada una de sus agencias no-conectadas una base de datos local en donde se registran las transacciones realizadas diariamente y que periódicamente se integra en la base de datos central solo la mínima información requerida posible (la requerida para efectos contables y de envió de información consolidada).

Por aquel año las grandes interrogantes eran: ¿Soportará dicho motor de base de datos (Adaptive Server Anywhere: ASA) el acceso concurrente de clientes locales y remotos? Y si esto es así ¿Los tiempos de respuesta serán aceptables o se necesitará optimizar los programas cliente para mejorar los tiempos de respuesta de la aplicación en su conjunto y así evitar los accesos innecesarios al servidor de BD?

Después de algunas pruebas de laboratorio, realizadas en la Caja NorPerú y en la Caja San Martín, llegamos a la conclusión de que efectivamente el ASA, administra aceptablemente bien el acceso de clientes remotos pero que tiende a "enchancharse" conforme aumenta el número de conexiones concurrentes.

A mediados del año 2001 este proyecto culminó exitosamente logrando que aplicaciones cliente de una agencia remota accedan a una única base de datos ubicada en la sede principal de dicha Caja. Cabe señalar que esta interconexión fue operativa y contable, es decir cada una de las agencias trabajaba como una oficina independiente y los usuarios involucrados (áreas de operaciones y de contabilidad) quedaron satisfechos bajo este nuevo esquema de trabajo.

Debido a que se percibía cierta latencia cuando se realizaban transacciones de créditos desde las agencias remotas nos embarcamos en otro proyecto con el objetivo de que las agencias más remotas accedan de una manera más eficiente a la base de datos central. En coordinación con el área de sistemas de la Caja NorPerú, se fijaron los siguientes objetivos para esta nueva etapa del proyecto:

1) En el corto plazo, optimizar la aplicación cliente para evitar accesos innecesarios a la BD o reemplazar bloques de código por algoritmos de acceso más eficientes.

2) En el mediano o largo plazo, considerar migrar su limitado motor de base de datos a uno corporativo. El candidato natural era el Adaptive Server Enterprice, también conocido con el nombre de ASE, de la misma empresa Sybase®.

A finales del año 2001 comenzamos a trabajar en la optimización de código de su sistema de información y en la creación de Objetos de Usuario No-Visuales (Non Visual Objects: NVO) que permiten encapsular las reglas de negocio de la empresa y más adelante colocarlos en un Servidor de Transacciones. Unos meses después este proyecto fue abortado por decisión de los funcionarios de la Caja NorPerú. Al parecer surgió un corriente de opinión de que con ese motor de base de datos (ASA) sería imposible interconectar sus agencias más remotas.

Años más tarde, y previa optimización de código como lo habíamos propuesto, su propia área de sistemas logró que agencias bastante remotas accedieran simultáneamente a única base de datos ASA centralizada usando conexión de línea dedicada.

Migrando de motor de base de datos

En el año 2004 la Caja Señor de Luren inició un proyecto de interconexión de agencias, tal como lo había hecho la Caja NorPerú en años anteriores, pero que implicaba además un cambio de motor de base de datos y la optimización de bloques de código de sus programas cliente.

En realidad había 3 proyectos en uno:

1) El proyecto de preparar los programas fuente de su sistema de información (plataforma cliente) y los objetos de la BD (plataforma servidor) para cada una de las estaciones cliente acceda en forma independiente a una misma BD centralizada.

2) El proyecto de migrar la data y absolutamente todos los objetos de BD de ASA (Adaptive Server Anywhere) a ASE (Adaptive Server Enterprice).

3) El proyecto de optimización de bloques de código de sus programas cliente para encapsular los accesos a la base de datos en objetos de usuario denominados NVO (Non Visual Objects) que a su vez accedían a la BD mediante Procedimientos Almacenados (Store Procedures).

Desde nuestro punto de vista, esto último es lo que causo los mayores retrasos en el proyecto. La razón de crear NVO 's es preparar su sistema de información para que en un futuro funcione bajo un esquema de 3 capas usando un Servidor de Transacciones como capa intermedia. Actualmente, según tenemos entendido, su sistema de información sigue trabajando bajo un esquema de 2 capas como inicialmente se diseñó.

Este proyecto lo llevó a cabo la empresa Sybase Perú y la duración de este proyecto fue de 1,5 años y su costo fue de US$150,000 dólares americanos (equipos, licencias y servicios). Estos son valores aproximados proporcionados por fuentes cercanas.

En el año 2005 la Caja NorPeru optó también por migrar de motor de base de datos (de ASA a ASE) pero solo haciendo los cambios mínimos necesarios a su sistema de información. Concentraron su esfuerzo solo en hacer upsizing de su base de datos, esto es migrar su motor de base de datos de pequeña escala ASA al motor de base de datos corporativo de la misma empresa ASE. No distrajeron su atención en otras consideraciones, y consideramos que fue una decisión acertada. Es importante recordar que por aquella época su sistema de información, en la parte Cliente y en la parte Servidor, ya trabajaba bajo un esquema de base de datos centralizado (esta adecuación se realizó en el años 2001). Solo requerían de un motor de base de datos de misión crítica que soporte una cantidad grande de conexiones concurrentes locales y remotas.

El proyecto lo llevó a cabo su propia área de sistemas lo que permitió un ahorro sustantivo de costos.

El costo aproximado de este proyecto fue de US$100,000 dólares americanos (equipos y licencias) y su duración fue de aproximadamente 9 meses.

Actualmente son las dos únicas Cajas Rurales en el Perú que poseen el sistema de información Hypatia trabajando con un motor de base de datos corporativo ASE en un esquema de base de datos centralizado. Actualmente la Caja NorPeru posee 12 agencias y la Caja Sr. de Luren 8, todas interconectadas (según su propio website), aunque al parecer esta última aún no soluciona hasta ahora su problema de contabilización automática bajo este nuevo esquema de interconexión.

Las otras 3 Cajas que poseen el sistema de información Hypatia trabajan con el motor de base de datos originario ASA.

Panorama de las demás Cajas Rurales

En el año 2005 la Caja Sipán convoca a nuestra empresa http-peru para realizar la adecuación de la versión del Hypatia que tenía hasta ese momento para que sus agencias accedan a una única base de datos centralizada (ASA). Se realizó un trabajo similar al que se realizó en años anteriores en la Caja NorPerú con el mismo resultado: la satisfacción total de los usuarios del sistema. A la fecha su sistema de información se encuentra trabajando bajo este esquema y realiza la contabilización de sus operaciones de forma automática, incluso las operaciones interagencias, pero no se priorizó el tema de optimización de código de los programas cliente, fundamental para el acceso concurrentemente masivo de clientes remotos.

A la fecha dicha Caja sigue usando el motor de base de datos Anywhere® (ASA) y no vemos que exista necesidad de cambiar de motor de base de datos en el corto plazo.

Otras experiencias
A finales del año 2005, la Caja Los Libertadores contrató a la empresa LogicCenter para resolver su necesidad de interconexión de sus agencias remotas. El objetivo inicial era permitir la interconexión de sus oficinas remotas y más adelante realizar operaciones de transferencias o remesas de efectivo con otras Cajas Rurales.

La solución propuesta implicaba el uso de su producto TransLink Transaction Services (TTS), un midleware que se constituirá en una plataforma de codificación intermedia entre las agencias remotas y la oficina principal.

Esta plataforma intermedia hará las veces de un Servidor de Transacciones, esto es, los requerimientos de las estaciones cliente de las agencias remotas serán procesadas por los componentes (programas) construidos sobre el TTS.

Algunas observaciones que hicimos a esta solución fueron las siguientes:

1) El costo de US$10,500.00 dólares por la adquisición del producto midleware TTS NO es el costo total de la solución. Se incurre en una serie de gastos adicionales, como por ejemplo el costo de contratar a las personas que van a programar los componentes que serán alojados en el TTS.

2) Las personas que van a programar los componentes no solo deben conocer detalles técnicos de la creación y publicación de componentes en el TTS sino conocer en detalle el sistema de información de la empresa y su dinámica de trabajo. Esto implica que no cualquier programador puede realizar esta delicada labor, sino que esta debe ser realizada por un especialista calificado que conozca las reglas de negocio de la empresa y sobretodo la dinámica de actualización de la BD implementada por su sistema de información, en este caso el Hypatia.

3) Se van a duplicar los esfuerzos de codificación ya que cuando se requiera agregar una nueva funcionalidad, o actualizar una ya existente, se deberá codificar en el sistema de información actual y hacer lo mismo en los componentes hospedados en el TTS.

4) Los tiempos de respuesta de los sistemas en .net, que al parecer es la plataforma tecnológica elegida, son notoriamente mayores que las soluciones en un entorno más abierto (php por ejemplo).

Meses después de haberse iniciado este proyecto, y producto de un estudio realizado por una tercera empresa, este iniciativa fue abortada.

Conclusiones Finales
El motor de base de datos ASA en un buen servidor de base de datos (multiprocesador, buena cantidad de memoria RAM y discos rápidos) administra aceptablemente bien el acceso de clientes locales y remotos. Soporta aceptablemente el acceso de hasta 120 conexiones concurrentes, 30% de las cuales pueden provenir de conexiones remotas (aproximadamente 6 oficinas). Para un número mayor de conexiones se debe considerar cambiar de motor de base de datos y/o optimizar la forma en que los programas clientes acceden a la base de datos (optimización de código).

Por la forma en que fue inicialmente diseñada, el sistema Hypatia realiza una gran cantidad de accesos a la BD saturando de requerimientos al servidor de base de datos. Esto se vuelve dramático cuando crece el número de conexiones concurrentes.

Para superar esto se debe rediseñar los programas Cliente para que realicen accesos optimizados a la BD y para que la información más frecuentemente consultada se encuentre permanentemente en los buffers de cada estación de trabajo.

Una muestra de lo que puede ocurrir cuando un motor de base de datos ASA recibe una gran cantidad de requerimientos de clientes locales y remotos, se produjo a mediados del año 2005 en la Caja NorPeru, cuando ya tenían 9 agencias y aún no cambiaban de motor de BD. No obstante tener un servidor de base de datos de última generación, su motor de base de datos ASA se constituyó en un cuello de botella ya que en horas punta este se saturaba y se degradaban los tiempos de respuesta del servidor. En aquel momento su sistema de información se constituyó en una debilidad para la consecución de sus planes de crecimiento empresariales.

Para superar esta coyuntura optaron por hacer uso de la fibra óptica como medio físico de comunicación entre su oficina principal y sus principales agencias pero no se consiguieron resultados espectaculares ya que lo que originaba el problema no era el medio sino el limitado motor de base de datos que en horas punta se "estrangulaba" y no se bastaba para satisfacer los requerimientos de clientes locales y remotos aceptablemente.

Migrar del ASA al ASE es una buena solución para esta clase de problemas pero los inconvenientes son los siguientes:

1) Es muy oneroso: Los costos directos (licencias) e indirectos involucrados lo hacen inaccesibles a la mayoría de las Cajas.

2) Soporte técnico: El soporte técnico en nuestro medio es escaso.

3) Mantenimiento: Este motor requiere de un dba con experiencia en este DBMS.

Las ventajas es que es un motor bastante sólido y estable y que es multiplataforma, es decir que puede correr bajo diferentes sistemas operativos: Windows, Unix, Linux, OS2, etc.