¿Reactivos o proactivos con la nueva tecnología?

Cuando se trabaja desde la consultoría a empresas uno debe tener claro la actitud que se debe de tener ante la tecnología emergente y como reaccionar ante ella de cara a lo que se ofrecerá a nuestros clientes, es probable que si nuestro cliente es un banco y aun siguen anclados al COBOL no haya muchos incentivos para proponer cambios y nuevas tecnologías core según que áreas (*), pero si el rubro de clientes apunta a los mal llamados proyectos “llave en mano” o “time and materials” en que se espera colaboración el escenario puede ser muy diferente, y el modo de proceder tiene que ser acorde a el.

Un error demasiado frecuente es dejar que sean las necesidades inmediatas de nuestros clientes las que condicionen la adopción tecnológica en una consultoría, como consecuencia los fichajes se hacen basados en si el desarrollador tiene los skills de los proyectos que se están haciendo en este momento, lo cual permite ir dentro de la ruta segura… por un tiempo, aunque puede generar situaciones extremas en las que por querer atender a un “cliente importante” se realicen fichajes de emergencia, o un aprendizaje a marchas forzadas, sin garantía de que luego de que ese proyecto acabe habrá nuevo uso de esa tecnología, pero bueno… lo importante es que se consiguió llegar a ese cliente (**). Otra situación común es que ante un potencial proyecto nuevo se este preguntando al equipo existente “¿alguien sabe xxx?” lo cual denota una falta de mapeo sobre los skills del equipo, pero eso es otra cosa.

El caso opuesto se da cuando alguien se emociona por una tecnología que se vio en Internet, y no se vio la curva de adopción, por lo que uno puede terminar casi sin soporte en Internet pues eres uno de los pocos que usa la tecnología, paso con lenguajes e IDEs en los 90s y ahora pasa con frameworks de JavaScript.

Entonces ¿que hacer? La respuesta esta tal vez en el medio, pero de una manera proactiva, no dejar de mirar los avances tecnológicos, en lugar de estar pendientes de lo que usa el cliente, apuntar a lo que la tecnología actual y emergente puede hacer por solucionar sus problemas y sus necesidades de crecimiento, investigar y hacer pilotos aun antes de que haya clientes que pidan algo (eso evita que el requerimiento o el boom nos coja desprevenidos) y como decia Eduard no pretender dominar todo y por ende aspirar a todos los clientes.

Adicionalmente, una “ventaja” de no estar en USA es que hasta cierto punto se puede sacar partido del retraso en adopción tecnológica, pues da tiempo para ver por donde se están consolidando las tendencias y ser novedosos (con algo seguro) de cara a lo que se le puede ofrecer al cliente.

¿Que opinan? ¿Reactivos o proactivos?

(*) A pesar de tener el core en COBOL muchas organizaciones han desarrollado productos con nuevas tecnología que llaman a ese backend, así que por ahí pueden salir las innovaciones a proponer.

(**) si a veces se esta en esa tesitura es necesario dedicar buen tiempo al estudio de lo nuevo, y no pretender que todos los desarrollos son similares ni con igual riesgo.

La eterna búsqueda de lo que agrega valor a los proyectos

Hay lecciones que uno las recuerda como si hubieran sido ayer, y esta si bien ocurrió hace como 18 años, la tengo siempre en mente cuando surge algo nuevo, pero… empecemos desde el principio.

Era una clase de Lenguajes de Programación 1, la dicto el profesor Alejandro Muñoz (un Ing. Civil con bastante pasión por los temas de informática) y el tema que tocaba era C++, para ese entonces ya habíamos aprendido Pascal (algunos laboratorios habían sido bien largos), Fundamentos de Programación y algunas cosas muy interesantes en Algoritmos y Estructura de Datos, pues bien, la primera sesión no se trato de explicarnos que incorporaba C++ sobre su antecesor C (el cual habíamos visto en la primera parte del curso), sino para plantearnos como surge la Programación Orientada a Objetos, como una respuesta a la Creciente Complejidad del Software, el cómo los programas tenían cada vez mas y mas líneas de código, por lo cual la Programación Estructurada ya había tocado su techo, siendo la OOP la respuesta al ser una nueva forma de ordenar los proyectos, así como para enfocar el código hacia entidades mas cercanas al mundo real.

Y claro, aun faltaban pocos años para que el boom de Internet nos cogiera por sorpresa, pero ahí nos quedamos con esa idea, la OOP como respuesta a todo, pero por otro lado vemos la aparición de Visual Basic y su enfoque RAD, en el cual (¡oh herejía) la OOP brillaba por su ausencia, pero aun asi permitió el desarrollo rápido de soluciones que si las hacias en C++ hubiera sido recontra complejo, claro que luego a alguien se le ocurrió una buena idea: mezclar el RAD de Visual Basic con el orden de la OOP y surgió Delphi, y asi hemos visto una sucesión de nuevas respuestas (nuevos retos, recuerden), como comente hace un tiempo , pero quien lo expone mejor es Esteban:
La primera aplicación que hice en mi vida profesional, fue una típica intranet para una empresa. Todo el código y acceso a la base de datos, se ejecutaba en archivos ASP.
Luego me dijeron que está mal acceder directamente a las tablas de la base de datos desde el código, por lo tanto implemente store procedures para cada uno de los accesos a la base.
Luego me dijeron que está mal mezclar lógica de negocio y de presentación en el mismo archivo…..
…..pasé de tener un simple archivo ASP (o ASPX, o JSP) a tener que crear un archivo HTML, una clase model, una clase controller, una clase repository de acceso a datos con su respectiva interface, una clase service que maneje la lógica de negocio con su respectiva interface, una clase para test unitarios, otra clase para test de integración, aprender a utilizar (como mínimo y básico) un framework MVC, ORM, de Unit Testing, Mocking, de inyección de Dependencias y de autenticación.
Todo para mejorar la productividad y velocidad en el desarrollo de aplicaciones. Todo para que el “desarrollador no pierda tiempo en programar aspectos secundarios de la aplicación y se concentre en lo mas importante, que es la lógica de negocio.”.
No se ustedes, pero a mi este ciclo de evolución del desarrollo de software me parece que esta muy alejado de la palabra “productividad”.

Efectivamente, esos han sido los vaivenes y trends por los que hemos pasado los desarrolladores en los últimos 15 años, es que efectivamente una vez que nos terminaron de convencer acerca de la OOP, eso no fue suficiente, tocaba programar basado “en componentes” y de ahí todo lo que cuenta Estaban en su post.

Y si, si bien esa historia puede ser descorazonadora para quienes producimos software debemos recordar algo:
• Siempre se nos pedirá mas y mas funcionalidades, y mas funcionalidades significan mas líneas de código, osea mayor complejidad.
• El entorno donde correrá tu aplicación cambiara, no tiene sentido pensar en tu web como la antigua aplicación de facturas hecha en Fox, porque ahí entran diversos factores que por mas que la funcionalidad sea “similar” a lo que ya había, cambian totalmente la forma en que la tendrás que desplegar y por ende estructurar el proyecto, baste mencionar el tema de seguridad y todas las consideraciones de zona militarizada que eso conlleva.
• Es impredecible saber con que interactuaran nuestras aplicaciones en el futuro, pero está claro que aun a la clásica aplicación de facturación se le puede pedir integración con Google Maps para que te ayude a ubicar la dirección del cliente.
• No puedes estar seguro de cuánto tiempo vivirá tu aplicación, pero alguien tendrá que mantenerla, por lo que hay que tener consideración con el que le toque hacerlo.

Llegados a este punto debemos reconocer algo, muchas de estas modas, surgieron para afrontar los retos que iban surgiendo progresivamente ante problemas que antes no había, o que terminaron volviéndose mas repetitivos terminandose al final conceptos ya asumidos “por defecto”: OOP, Web, BD relacionales, SOA, etc; ahora bien, eso no quita que hubo muchas soluciones para necesidades inventadas, por lo que pasaron sin pena ni gloria (¿alguien recuerda los “behaviours” en IExplorer 5?).

Ahora bien, el problema que debemos afrontar es saber cuándo seguir o no una tendencia (ya me paso a mí con LINQ 2 SQL, pero pese a ello era claro que los ORM habían venido para quedarse) y sobre todo si esta aporta real valor a nuestra solución, ya exprese mis dudas respecto a los nuevos patrones de diseño, pero de nuevo Esteban nos ofrece su visión de porque algunas cosas se terminan imponiendo (sin necesidad): Assumptions Driven Development. Es que es así, implementamos por inercia cierta arquitectura (de moda) sin tener en cuenta cual es el escenario real para la cual esta tiene sentido, o porque esperamos que cierta condición se cumplirá en el futuro y para ello “hay que estar preparados”, y como bien se apunta en el articulo esas condiciones nunca terminan de cumplirse pero en el camino ya hemos agregado complejidad innecesaria a nuestro proyecto.

No es sencillo, la verdad, pero como dije al final algunas cosas vinieron para quedarse: OOP, aplicaciones distribuidas, nuevas interfaces de usuario mas ricas, interconectividad, y ante ello no queda sino tener la suficiente cabeza fría de saber si la novedad que estamos queriendo implementar en nuestro proyecto agrega valor o no al producto a ser entregado, si los retrasos y complejidad añadidos son superados por las ventajas futuras (a veces puede que no ), la cosa es no temer a la respuesta de un análisis hecho a conciencia.

Por ejemplo, estoy convencido que ciertas capas de las aplicaciones pueden beneficiarse muchísimo del uso de pruebas unitarias, componentes algorítmicos puros, formulas matemáticas, financieras, su determinismo es tan alto que una prueba unitaria de veras se luciría para probar el código, pero de ahí a querer una cobertura del 100% o plantearse el TDD como panacea para mejorar la calidad de los programas… me lo tomo con pinzas, a riesgo de que me llaman hereje indicando que he “missed the point”.

Ojo, nótese que prudencia no es pasividad ni conformismo, pues de lo contrario estaríamos como las empresas que siguen usando mainframes.

Si, es complicado, pero es mejor tener las cosas claras y no renunciar al análisis para saber separar la paja del trigo.

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

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.

¿Se requiere soporte para Internet Explorer 6/7 ahora?

Pues justo ahora que comentaba sobre si al final Google lograria que Internet Explorer desaparezca, leo esta nota en Slashdot:

“Following Google’s announcement ending support for Internet Explorer 6, I find myself wondering whether we (Web developers) really need to continue providing support for IE6 and IE7. Especially when creating Web sites intended for technical audiences, wouldn’t it be best to end support for obsoleted browsers? Would this not provide additional incentives to upgrade? Recently I and my colleagues had to decide whether it was worth our time to try to support anything before IE8, and in the end we decided to redirect any IE6/7 user-agent to a separate page explaining that the site is not accessible with IE 6 or 7. This was easy once we saw from our analytics that fewer than 5% of visitors to the site were using IE at all. Have you had to make a choice like this? If so, what was your decision and what was the reasoning behind it?”

En resumidas cuentas, se cuestionan si en estos tiempos los desarrolladores de Web deberían seguir dando soporte a browsers obsoletos, siendo que era mejor redireccionar a los usuarios a una advertencia diciendo que el sitio no era accesible en IE 6 o 7, lo cual fue fácil ya que menos del 5% de los usuarios usaban IE.

Razonamiento simple ¿verdad? es mas, yo lo seguiría en la mayoría de los casos en que tuviera un site abierto, dedicado al publico masivo, pues me interesaría contar con elementos actuales que faciliten la programación de una mejor experiencia de usuario, pero……

Hay veces en que la disponibilidad y usabilidad de tu site estan definidas por un contrato, y este contrato no es con un usuario final individual sino con una institucion (ya sea publica o privada), por lo que si luego de una pequeña modificación en una pagina, te llama un cliente quejándose de que no le funciona la Web usando IE 6 (o IE5) no tienes sino que revisar y hacer que la aplicación vuelva a funcionar. Es por esa razon que antes de hacer un pase a producción de un cambio de plataforma (sin cambiar contenido) tuve que dedicar un buen rato a levantar Maquinas Virtuales(*) a fin de comprobar que el site seguia operativo en plataformas “antiguas”.

En circunstancias como esta ¿Que queda por hacer?, todo depende, lo mas seguro es avisar con unos cuantos meses de anticipación (seguramente mas de los que ha dado Google) de que llegada cierta fecha no se dara soporte a ciertos browsers, o de ser el caso esperar la siguiente renovación de contrato para introducir dicha condicion.

El punto es, que si bien lograr el cambio es difícil, las empresas que se encuentran en una situación como la descrita pueden ser los mejores agentes para lograr el abandono de IE6, mas aun que Google, ya que si una organización sigue usando internamente un browser obsoleto, el que venga una orden “de arriba” indicando que hay que hacer el cambio sera mucho mas efectivo que un empleado normalito quejándose que no le funciona el Gmail. Aunque claro, esto traera el efecto colateral (positivo) de que esta empresa cliente también deba actualizar sus webs.

Actualizacion 21-2-2010 Gracias a Slashdot he encontrado este interesante articulo donde se investigan las razones por las que las empresas aun siguen sin actualizar sus browsers, es que … ¡simplemente no actualizan nada! (ademas de otras interesantes razones que invito a leer).

(*) Esto porque IE ha mantenido la política de no permitir mas de una versión en un mismo equipo, y que por ejemplo no puedes instalar IE4 en XP, o IE6 en Vista.

¿Funcionara la amenaza de Google para reducir a Internet Explorer 6?

En realidad es un tema que ya habia estado dando vueltas desde hace rato, y volvió a tomar relevancia cuando Microsoft empezo a pedir a sus usuarios que actualicen a Internet Explorer 6.

La verdad es que la posicion de Microsoft es algo complicada, ellos estan obligados por su propio contrato a dar soporte a los elementos con los que vino instalado Windows XP (alla por el 2001), siendo que Internet Explorer es parte de esa instalación, es mas ya sea que uno instale XP SP3, o aplique SP3 sobre una instalación ya existente, el browser instalado (a menos que uno lo cambie manualmente) es Internet Explorer 6.

Bueno, Microsoft ha hecho algunas cosas sutiles para ir conduciendo a los usuarios a que vayan actualizando su browser, asi, si bien los contenidos generados por un servidor MOSS pueden ser vistos en IE 6, para poder administrar el servidor se necesita IE 7 o superior, no es mucho pero algo es algo.

Y la verdad es que esa migración no se producirá a menos que los usuarios estén convencidos de ello o no les quede mas remedio so pena de no poder seguir trabajando o realizar cosas que les sean de veras importantes, por lo que la idea de que los blogs tengan un plugin que malogre la experiencia de navegación en IE6 a efectos prácticos no paso de una anécdota.

Pero la cosa cambia cuando Google anuncia que dejara dar soporte para IE6 (osea que practicamente dejaran de funcionar) en aplicaciones como Google Docs primero y Gmail luego, movimiento sin lugar a dudas de veras desequilibrante teniendo en cuenta la popularidad de la plataforma de correo de Google.

Asi pues, dada la ubicuidad de Google, se podria decir que el fin de Internet Explorer 6 en los escritorios esta cerca ¿ o no?, para estar seguros debemos analizar dos de los huesos mas duros de roer en cuanto a la actualizacion tecnologica:

Cabinas, Locutorios y Cibercafes Como comentaba hace unos meses estos negocios solo se mueven bajo la premisa de que las maquinas estén funcionando, instalan siempre un mismo patrón de aplicaciones, nunca corren el Windows Update, si entra virus, pues nada… a formatear y a seguir adelante, y claro si un usuario se quejo porque algun blog colgo el browser, dicha queja se solucionaba con un “cambiate de maquina”, solucion que ahora ya no podra ser efectiva cuando el usuario no pueda entrar a ver su Gmail, asi que quieras que no el cabinero deberá establecer una nueva plataforma base para sus equipos so pena de que los usuarios se alejen de su local, y como el dinero manda, creo que en ese sector si veremos el cambio.

Empresas Lo mas complicado, una empresa de mediana tirando a grande tiene totalmente restringido lo que el usuario puede hacer (supongamos que le deja salir a Internet), siendo que en un temor de que nada “extraño” entre demoran infinitamente el despliegue de los Service Packs, no ejecutan el Windows Update, aun cuando el parche a desplegar sea muy critico, y por supuesto… solo usan un browser: Internet Explorer 6. Ya centrándonos en el browser, las razones son diversas: tener equipos homogéneos para que sea mas sencillo dar soporte (plan que se va al carajo cuando los gerentes empiezan a estrenar modernisimas laptops con Vista entonces y con Windows 7 ahora), y la mas común y mas valida, garantizar la ejecución de aplicaciones diseñadas cuando IE6 era standard de facto, ya que a menos que se este planeando hacer una migración del parque de aplicaciones Web, la organización debe velar para que lo que funcionaba entonces siga funcionando ahora, y créanme, muchas aplicaciones complejas pueden simplemente empezar a fallar si no se las usa en el browser correcto, y el tiempo de parchado … cuesta. Así que en ese sentido no creo que un administrador de red este por la labor de ayudar cuando una secretaria se queje de que su Gmail ha dejado de funcionar.

Así pues, la amenaza de Google significara un avance, pero creo que el mayor avance se dará cuando las empresas terminen de evaluar a Windows 7 y decidan hacer un despliegue general, circunstancia en la que los parchados (o migración integral) de las Aplicaciones Web existentes tendrán que hacerse si o si, o si no educar a los usuarios en el modo de Compatibilidad de Explorer 8.

Ya sea por una razón u otra, a ver si terminamos de sacar a IE6 de nuestros equipos, las versiones anteriores de IE y Netscape entraban y salían de nuestros equipos muy rápido, en cambio IE6… esta siendo mas persistente que lo esperado.

CNET: Microsoft actively urges IE 6 users to upgrade

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.

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