Categoría: Cobol

¿Que hace que una tecnologia resista mas alla de su ciclo de vida?

Posted on by ecardenas

Hace exactamente 3 años comentaba la situación en la que se encontraban muchas empresas, ancladas al pasado tecnológico con tecnologías de mas de 20 años, y de paso enlazando tecnologías que estaban muriendo o agonizando: Cobol(*), Bases de Datos no Relacionales, redes no TCP/IP, ccMail, ColdFusion, C (puro, no C++), PowerBuilder, Netware, PC network y OS/2; claro esta que a esa lista añadiria xBase (¿se acuerdan cuando casi todo pequeño negocio tenia su aplicación en Clipper o Fox para DOS?).

Ya sabemos que aun en pequeños negocios como cabinas de internet cuesta de convencer el migrar hacia tecnologías mejores y mas eficientes, pero aun así al ver la lista mencionada uno ve que el estado de estas tecnologías es mas bien dispar, algunas tecnologias estan realmente muertas o terminando de morir en sus ultimos espacios, mientras que otras a pesar de no brindar nada nuevo, siguen siendo la base para nuevos desarrollos, conviviendo con otras tecnologías.

¿Qué es lo que hace que algunas resistan y otras no? Especulare un poco y a ver si comparten mis ideas.

1)La ola es muy fuerte y no puedes sino dejarte llevar, si, en este caso estamos hablando de Internet y el efecto de arrastre que implico para la adopción del protocolo TCP/IP como la opción por defecto en las organizaciones, todo Ethernet, adiós token ring, protocolo IPX…. lo cual de rebote termino cargándose a las redes Netware de Novell, antaño bien implantadas en muchas organizaciones. Así que si todos los proveedores, incluyendo los de mainframe, deciden dar el salto al soporte de TCP/IP (como ocurrió en la segunda mitad de los 90s) el cambio ya es inevitable. Por mas que algunos digan que Internet resucito un protocolo que ya era «cadáver», al final la inercia del mercado y la demanda por conexión a Internet nos arrastro a todos, y ya no miramos atrás.

2)El costo de mantener la compatibilidad es muy alto comparado con la migración, aquí ya entro un poco en la especulación basándome en lo que he visto en las pymes, quieras que no el mercado de aplicaciones para pymes es muy dinámico y llega un momento en que ya no se pueden mantener las aplicaciones existentes por: no se pueden encontrar profesionales, o porque eventos como la introducción de Windows 95 o el problema del año 2000 te hacen sacar la calculadora y ver que mas barato te sale migrar que seguir manteniendo tu querido Clipper.

3)Lo que elegiste no era tan masivo y cada vez te costara mas encontrar soporte, aquí caen dos tecnologías al margen de sus méritos: Delphi y PowerBuilder, efectivamente ofrecían una buena respuesta tecnológica a las necesidades de desarrollo en Windows de esa época (mejor que VB en el caso de Delphi, p. ej), pero la presión introducida por el desarrollo de aplicaciones Web, así como la pujanza de .NET y Java, hizo que el nicho de mercado que se había construido alrededor de estas tecnología se debilitara impulsando su migración. Lo bueno en este caso es que la arquitectura modular de estas tecnologías (el entorno de desarrollo de la aplicación no esta amarrado a la BD como en xBase) permite migraciones menos traumaticas y mas progresivas.

4)Es mas caro migrar que mantener la compatibilidad si, al revés que el caso 2) y en este caso nos topamos con los engreídos de la industria: el mainframe ya sea en sus variantes PL/1 o COBOL, están ahí, las empresas se resisten con uñas y dientes al cambio, por la sencilla razón de que debido al volumen y trafico de información, el riesgo de tener la producción caída es algo que no se puede asumir, punto. Es curioso que cuando hubo el problema del años 2000 en algunos casos se haya optado por una huida hacia adelante, parchando la infraestructura en vez de aprovechar la oportunidad de reemplazo. Y así como están las cosas, se requerirá mucho valor y cabeza fría para que una organización decida migrar sus aplicaciones, pero la verdad…. ¿de veras tiene sentido basar lógica de negocio en la posición de un carácter en un texto plano?

5)Entenderlo es mas complicado que parcharlo esta es la peor situación de todas, pues la limitación viene dada no por las características de la tecnología, si no por como esta tecnología no te coloca restricciones para hacer mal código, concretamente Visual Basic 6 cae en esta categoría, ya que como comente antes es perfectamente posible construir aplicaciones en VB6 con una arquitectura robusta y buenas practicas (y he visto buenas aplicaciones de este tipo), pero la propia filosofía del lenguaje no te impulsa a ello, recayendo totalmente en el desarrollador y la organización el montar algo ordenado, siendo que una vez empezado el trabajo esa reorganización es tarea imposible. Resultado: que esas aplicaciones se mantengan, crezcan y crezcan a golpe de parches, haciendo la migración algo temido por la organización, haciendo que VB6 ya sea considerado como el nuevo COBOL, con la diferencia de que el soporte y evolución quedo cerrado hace rato, así que solo resta esperar una nueva revolución que nos fuerce a dejarlo.

Esto es, dentro de mi experiencia, lo que creo que establece diferencias entre los destinos de diversas aplicaciones, me quedo con la curiosidad de saber cual ha sido el proceso por el que pasaron tecnologías como ADABAS, mainframes NCR y AS/400.

(*)Aunque yo lo consideraría de la mano de su hermano en mainframe: PL/1.

Decisiones como los cangrejos…

Posted on by ecardenas

Por alguna razon me acabo de acordar un mail que me mando mi amiga que esta en Chile preguntando que seria necesario para migrar de C++ a C. Eso fue hace unos años pero aun asi sirve como ejemplo para ver como algunas decisiones se toman de manera poco estrategica.

El caso es que se tenia un proyecto desarrollado para una plataforma de comunicaciones, y habia sido desarrollado en C++ (osea orientado a Objetos) pero que por una migracion se requeria tener la misma funcionalidad en una plataforma cuyo compilador solo soportaba C (estructurado) y no C++. Conteste a mi amiga de que habria que convertir las clases a estructuras y definir una nomenclatura que sirva para identificar las funciones para que mapeen los metodos de las clases…. pero en fin.. tenia un pinta de ser una tarea titanica, suerte que al final ella no se hizo cargo.

Esto viene a proposito de tendencias que vemos en las empresas, anclarse a plataformas obsoletas o con fabricantes absorbidos/desaparecidos, todo porque se considera que la logica de negocio ya esta estable, que el costo de migrar seria superior y la mas comun… «es que el mainframe es mas robusto», «esta nueva tecnologia aun no esta probada» todas son excusas que al final se agravan en los casos de integracion de sistemas.

Los efectos visibles los habremos visto frecuentemente, sistemas criticos dependiendo de miles de lineas de codigo en COBOL, mismos que requieren constantes ajustes y mantenimientos que no pueden beneficiarse de conceptos como arquitectura de servicios, XML, WebServices, y en algunos casos ni siquiera Orientacion a Objetos, esto porque se siguio un proceso de mantenimiento continuo mas no de evolucion de los sistemas, a lo sumo una adaptacion de interfaces para su conexion con nuevas tecnologias, pero…. cambiar mi amado y superpoderoso mainframe con COBOL? ni hablar!!! Un resultado muy visible se vio cuando hubo que solucionar el problema del año 2000, se comentaba que en algunas empresas se tuvo que traer a programadores jubilados para que estuvieran en el proceso de parche, ya que estos eran quienes habian estado durante el desarrollo original.

Cierto, no es que debamos cambiar por cambiar, sino hacer un analisis de las nuevas tecnologias y sus perspectivas de evolucion, no vaya a ser que pase como quienes apostaron por las WebClasses, ColdFusion, o Visual J++, pero a estas alturas… desconfiar de los servidores de bases de datos relacionales??? (pues si a estas alturas hay quienes aun les tienen alergia).

Ironicamente se da el caso de empresas que acometen renovaciones periodicas de ciertas partes de su plataforma, especialmente la de los usuarios finales, pero claro… el nucleo hecho en mainframe… ni tocarlo, pero eso si.. a montar toda una super arquitectura Web mediante SOA y XML, como me paso en un proyecto donde todo era muy moderno en teoria, pero el mainframe era incapaz de generar XML para ser consumido (por lo menos eso podria hacer, no?) asi que otro modulo era el de conversion de tramas, eso si… no les falto valor para introducir AJAX en las etapas finales del proyecto…. alucinante de veras, se pasan defendiendo al mainframe por ser algo «ya probado» pero a la hora de los loros meten una tecnologia recien probandose… en las etapas finales del proyecto.

El caso es de que a veces se pierde la vista de que las Tecnologias de la Informacion deben cumplir un rol como ventaja competitiva para la organizacion, o en todo caso facilitador de sus procesos, pero lamentablemente vemos como persiste la dependencia a los «legados» lo cual lleva a problemas de mantenimiento debido al parche tras parche, y ahora la dificultad (y el mayor costo que eso conllevara) para encontrar personal dispuesto a trabajar en dichas tecnologias, como se manifiesta en el hecho de que buena parte de los reclutamientos que hizo una empresa española en Peru fueron de programadores para mainframe, es que claro… las nuevas generaciones saben de que va eso asi que evitaran tratar de enfocar su carrera en el uso de dichas tecnologias, y si en Peru aun es factible encontrar este tipo de programadores… es un sintoma de que algo se esta haciendo mal por ahi.

Anclados al pasado tecnologico….

Posted on by ecardenas

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?)