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?)
Sí pues…
(se me cortó el comment anterior)
la resistencia al cambio es real y FATAL.
Aunque soy informática 30 years old, jamás trabajé con un Mainframe y siempre he odiado al COBOL sobre todas las cosas.
Pero ver una máquina trabajando décadas en estos tiempos tan efímeros tiene su belleza.
Los departamentos de Sistemas tienden al mínimo riesgo y eso lleva a veces a decisiones iracionales de mantener lo que ya no tiene sentido. Pero otras veces han cambiado el mainframe por una modernez y y han sufrido mucho.
Es triste, pero el SW actual es menos robusto que el que se hacía hace 30 años.
Hablando de nostalgias, he trabajado en dos proyectos de telecomunicaciones: el TESYS A (un conmutador de paquetes) que vivió 20 años y estaba programado en PLM y el MORE (un conmutador de circuitos) programado en C que tenía una esperanza de vida de 10 años y yo creo que llegará la veintena también.
Y si quieres conocer un caso de status quo curioso sigue este link http://bit.ly/daeEBO