¿En que escenario se justifican los procesos en lotes?

Procesos por lotes (o batch) por lo general son los que involucran una fuente (generalmente temporal) de datos que tienen que ser procesados y/o integrados en una repositorio de destino. Generalmente se hace periodicamente o cuando se alcanza cierto volumen que justifique el realizar el proceso.

No toca aca discutir las cuestiones tecnicas de dichas tareas, que si se hace con transacciones o no, performance (solo debo comentar que por performance a veces no se trabaja con integridad referencial), si se va contra mainframe o no, sino el ir un poco mas alla de la racionalidad detras de la decision de usarlas, para lo cual me remitire a dos ejemplos que conozco de primera mano.

1) Para el que no lo sabe en España existe una Ley de Proteccion de Datos, que entre otras cosas permite al ciudadano el decirle a una empresa X que no quiere seguir figurando dentro de sus archivos (sobre todo si no eres cliente), en el caso que nos ocupa un usuario habia pedido a la empresa X dicha baja en la base de datos a fin de no seguir recibiendo publicidad, todo ok hasta ese momento, pero resulto que a poco de haber hecho esa solicitud recibio comunicacion publicitaria por parte de X, con lo que el usuario en cuestion denuncio a X por violar la citada Ley, que habia pasado? simple que la informacion sobre las bajas no era procesada automaticamente sino que se guardaba en un repositorio temporal, el cual era volcado periodicamente a la Base de Datos principal a fin de dejar constancia de las bajas (y supongo que tambien las altas) producidas, resultando que la comunicacion esa habia sido hecha en el intervalo entre la solicitud y el volcado respectivo, con el consiguiente perjuicio para X al haber violado la ley (pero no intencionadamente debo decir).

Eventualmente el procedimiento cambio aunque no se si para realizar las bajas en tiempo real o solo para incluir una advertencia al usuario acerca de que la baja no es automatica.

2) Estoy afiliado a Openbank, realizando practicamente todas mis operaciones via Internet o por Telefono, tan asi que en mas de 7 años solo he ido 4 veces a sus oficinas, el caso es que en ciertas ocasiones he necesitado realizar operaciones (via tarjeta o cajero) de monto mayor al limite de proteccion que tiene el banco, llegando a hacerlo por telefono en pleno establecimiento comercial, lo cual era procesado automaticamente, lo cual me parecia una ventaja en ciertas ocasiones; pues bien hace unos meses llame para realizar dicho procedimiento y me dijeron que lo hacian pero que tendria vigencia a partir del dia siguiente, ¿por que? porque habian cambiado sus procedimientos y en lugar de efectuar las ordenes y movimientos en tiempo real ahora se efectuaban en lotes entre las 10pm y la medianoche. Consecuencia directa: que el acceso a la web se vuelve mas lento en esa franja horaria y se pierde un servicio que resultaba muy conveniente para los clientes del banco, pero no solo ese servicio, sino tambien los pagos y transferencias, de hecho este lunes llame a la 10:20pm para ordenar una transferencia a otro banco, diciendome que dicha transferencia se haria efectiva hoy miercoles en la mañana, pero al final al verificar en la web resulta que la “Fecha valor” es …. mañana!!, ahora vete tu a saber si el banco destino lo hara efectivo inmediatamente, al final resulta que los envios de dinero que hago a Peru llegan antes que una transferencia dentro de España.

Son estos casos de uso evidente de procesos por lotes, se justifican sus posibles beneficios frente a los serios inconvenientes causados? lo dudo mucho.

Pero, siendo asi, ¿existen situaciones en la que sea necesario el usar procesos por lotes?, si, pero creo que en el escenario tecnologico actual solo cuando sea estrictamente necesario, osea cuando se trate de consolidar sedes remotas y la conexion no sea tan eficiente y sea necesario esperar a acumular operaciones para luego transmitirlas de manera comprimida (y espero que encriptada), luego se me dira que tambien podria ser necesario cuando el costo de la transaccion sea muy alto, pero antes de optar por ese camino habria que pensar si no es peor degradar la performance en el momento en que deciden ejecutarse de golpe todas esas transacciones, teniendo el añadido de que si tu negocio es online y supuestamente 24×7 uno no puede permitirse ese lujo.

Alguna otra idea para un escenario tolerable para los procesos en lotes? No, no me refiero a procesos de facturacion, nominas/planillas o informes periodicos, sino a movimientos cuyo registro afectan de un modo u otro las operaciones del dia a dia de la organizacion y/o la satisfaccion de los clientes/usuarios.

Anclados al pasado tecnologico….

Hace como 12 años en una clase de Ingenieria de Software en la PUCP el profesor comentaba que esa epoca era una buena oportunidad para empezar las cosas bien, ya que como muchos bancos se estaban creando se podia arrancar con plataformas recientes y no dependientes en mainframes y el COBOL. Muy pocos años mas tarde hablando con una amiga me conto que su trabajo consistia (entre otras cosas) en la integracion de plataformas para uno de esos bancos mediante C y acceso a COBOL, debo reconocer que entonces me sorprendio mucho pero resulto que la razon era muy simple para que no se cumplieran las afirmaciones de mi profesor, resulta que al instalarse dichos bancos como venian de una matriz chilena decidieron que lo mas sencillo era utilizar como base toda la tecnologia usada en las matrices…. conclusion.. una oportunidad perdida.

Y esa es una constante que veo a nivel global… una resistencia al cambio sobre todo si estas muy dependiente a tecnologias antiguas como el COBOL y los mainframes, las excusas son clasicas “llevan buen tiempo funcionando”, “el mainframe es solido”, “te arriesgarias a que esto dejara de funcionar?” y cosas asi, pero al final es inevitable que las necesidades de negocio evolucionen y por lo tanto surja la necesidad de exponer la informacion en mas plataformas (Windows para cliente final institucional, Web para tu publico) por lo que terminamos desarrollando capas y mas capas para enmascarar el acceso a estas plataformas y poder integrarlas con las herramientas actuales. Que si.. luego diran “ya ves como funciona?” si, pero mas por merito de los equipos de desarrollo que por merito de la herramienta, que ahi esta ..lanzando sus tramas… sin transacciones.. sin integridad referencial, y dale nosotros a mapearlo a XML o a alguna trama de datos mas actual.

Me diran que no hay que ser un loco de la tecnologia y mucho menos en una empresa, que no hay razon para tener que estar siempre a lo ultimo y tienen razon, las decisiones tecnologicas deben ser un proceso razonado de cara a lo que la organizacion espera, siendo los sistemas de informacion quienes deben alinearse a los objetivos de la empresa, asi que si los requisitos que nos exige el entorno cambian se debe pensar que tanto nos tira para atras los parches que hay que hacer para que el sistema legado siga encajando en la organizacion.

Es muy probable que organizaciones que tengan BD relacionales de 10 años de antiguedad no tengan necesidad de cambiarla, lo cual me parece muy valido puesto que los entornos de desarrollo actuales proveen mecanismos de integracion con esta clase de sistemas de manera muy transparente, con lo cual es mas o menos sencillo la renovacion de aplicaciones utilizando tecnologias nuevas sin necesidad de actualizar todas las BD, pero justamente dicha transparencia esta ausente en los sistemas legados que vienen desde los 80s y antes, lo digo por experiencia propia ya que en un proyecto para Web se actuaba contra una plataforma mainframe, y como se decidio usar XML como mecanismo para el pase de informacion entre capas, el detalle es que para esto se tuvo que inventar una arquitectura que permitiera esa integracion ya que de por si el mainframe no era capaz (ni habia upgrades que lo permitieran) de generar XML por su cuenta, por lo que buena parte del tiempo de desarrollo en esa empresa correspondio al modelamiento del medio antes que en los procesos de negocio en si.

En cierta forma las aplicaciones hechas en xBase,VB6/4/5,Delphi y PowerBuilder tienen un ciclo de vida diferente que permita una evolucion menos traumatica, lo cual nos permite tomar las cosas con calma y ver que su presencia no es tan lastre, pero definitivamente considero que una evolucion estrategica del departamento de IT de una empresa deberia plantearse el como progresivamente ir librandose de plataformas que obligan a cantidad de malabares tan solo para lograr un medio de integracion en lugar de permitir ir directamente a la solucion de los problemas de negocio. Hagamonos un favor y limpiemos progresivamente de COBOL a las organizaciones.

Es interesante leer: Habilidades informaticas muertas o agonizantes(a que no adivinan cual es la primera?)

Futura fusion del Banco Wiese y el Sudamericano …. y?

Al despertar veo los titulares y me entero de que el ScotiaBank comprara el Banco Wiese Sudameris (BWS), noticia que usualmente seria solo el cierre de una cadena de anuncios, marchas y contramarchas, pero que ahora incorpora el hecho de que esta adquisicion incluye una fusion a mediano plazo entre el Banco Sudamericano (cuyo accionista fundamental es precisamente el ScotiaBank).

Quedan pendientes muchos temas, plazos de la fusion, el destino de los empleados (otra ola de despidos en ciernes como cuando lo del BSCH??), el pago del aval que emitio el Estado Peruano, los nuevos dueños dan unas breves pistas sobre estas cuestiones, pero no mencionan un tema que es de mi particular interes: la integracion de sistemas.

Es sabido que cada organizacion (y mas una del tamaño de un banco) en el conjunto de los años ha desarrollado e invertido en una arquitectura y conjunto de plataformas para dar soporte a sus operaciones, dependiendo de cuan innovadora o conservadora sea esta organizacion cada paso se medira con ciertos criterios, atendiendo entre otras cosas a criterios de compatibilidad con las plataformas anteriores y particularmente en el caso de un banco a no afectar las operaciones de la organizacion.

Hay ocasiones en las que una organizacion decide (o la falta de soporte decide por ella) que sus plataformas legadas no son convenientes para servir de apoyo a los nuevos retos que tendra que afrontar, decidiendo la migracion a alguna nueva arquitectura; tradicionalmente han sido los bancos y empresas afines las mas “reacias” a tomar esos riesgos, medida comprensible en parte por la criticidad de sus operacion y por otra parte por la presion ejercida por los proveedores (interesados en no perder la respectiva cuenta). Consecuencia de lo anterior es que la introduccion de nuevas tecnologias se hace de manera evolutiva y por capas, asi que por mas que veamos que un banco tiene unos super terminales en sus oficinas y una modernisima aplicacion web es mas que probable que lo que este dando soporte a esa operaciones sea un mainframe….. modernizado y todo pero que no deja de ser tecnologia de mas de 20 años.

Recuerdo particularmente que a mediados de los 90, un profesor mio de Ingenieria de Software nos decia a proposito de la apertura de nuevos bancos en el Peru que esto era “una oportunidad para que un banco empiece desde el principio utilizando tecnologia actual”, ingenuo de mi lo crei por unos años hasta que converse con una amiga que trabajo dando servicio a algunos de estos bancos quien me conto que la realidad era otra: como varios de estos bancos eran de origen extranjero lo que se hizo basicamente fue copiar la arquitectura de las matrices a la hora de establecer los nuevos bancos peruanos, y ya se imaginaran … los flamantes nuevos bancos basaban sus operaciones en… COBOL (lenguaje de programacion originado en los 50s)!!!!

Teniendo en cuenta esta realidad sobre las plataformas base, hay algo que por fuerza rompe los esquemas y es el caso de una integracion como la que motiva esta nota. Ingenuamente creia que en el momento de la fusion se evaluaba cual de las plataformas a integrar era mas conveniente no tanto por solvencia tecnologica, sino por volumen de carga actual (cual de las dos org. mueve mas informacion dia a dia) y flexibilidad para dar soporte a la mayor parte de los modelos de negocio de la otra organizacion, pues no, la realidad es mucho mas prosaica y simple: politica y poder. Vale decir que quien pone la plata decide cual es el camino, asi que para esto contare dos casos que he visto mas o menos de cerca para ver la realidad (comprenderan que no mencione nombres, pero son caso veridicos).

A tiene mas operaciones que B, A usa una plataforma solida, difundida y con respaldo, B usa una plataforma que tuvo sus 15 minutos de fama en los 80 pero que en los 90 tuvo que ser adquirida por otra corporacion que no innova esta linea pero al menos da soporte. B “la pequeña” es adquirida por una corporacion internacional que la usa como puente para la adquisicion de A. Resultado: la plataforma de B sera el soporte de la nueva organizacion AB causando problemas (transaccionales y de drivers por si te interesaba la marcianaba) a la hora de portar los desarrollos hechos por A.

La corporacion M decide adquirir a “n”, una empresa pequeña dentro de su sector, la cual habia desarrollado una logica de negocios agil que habia permitido una cierta rentabilidad y bajos costes, en la integracion se informa que la plataforma de “n” sera dejada de lado y se usara la de M casi 10 años mas antigua, usando un modelo de datos que no cubre totalmente las necesidades de logica de negocio que dieron agilez y rentabilidad a “n”, a usar calzador se ha dicho.

Visto estos antecedentes uno ya puede preveer cual sera el futuro de esta integracion, el BanSud marcara la pauta tecnologica de la nueva organizacion, no importando si la del BWS pueda ser mejor (que no lo se), el tamaño de la cartera de clientes, el volumen de operaciones ni la implantacion a nivel nacional, esa es mi apuesta, ojala me equivoque y primen mas los criterios tecnicos y no politicos.