Decisiones como los cangrejos…

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.

Agregue un comentario

Su dirección de correo no se hará público.

Time limit is exhausted. Please reload the CAPTCHA.