Arrastrar las aplicaciones heredadas a la era moderna es un pilar clave de las estrategias digitales actuales. También es más difícil, más costoso y menos gratificante de lo que cree.

Más del 95% de las empresas de Fortune 1000 todavía utilizan IMS, el antiguo DBMS jerárquico de IBM. Al menos, ese es el número según TwoBitHistory.org.

Mi propia encuesta informal, por el contrario, revela que aproximadamente el cero por ciento de los mejores desarrolladores de TI tienen algún interés en trabajar en ese entorno.

La capacidad de atraer a los mejores talentos es una de las razones, no la única, sino una de las más importantes, para que los CIO modernicen su cartera de aplicaciones. Otros incluyen tarifas reducidas de licencia y soporte, y mayor flexibilidad y adaptabilidad.

Sin embargo, la “modernización” no es una propuesta tan sencilla como podría parecer. Tiene secretos oscuros que los CIO inteligentes deben tener en cuenta en su toma de decisiones.

1. La modernización de las aplicaciones es un problema complejo

La modernización de la aplicación (“mod de aplicación” si es miembro del Cool Kids Club) cubre un montón de soluciones muy diferentes para un montón de problemas muy diferentes.

Dependiendo de la aplicación y con quién hable, la modificación de la aplicación puede significar la actualización de la versión, la reestructuración, el reemplazo de la plataforma, la modernización del idioma, la refactorización o la conversión COTS. Si bien a todos se les llama “modernización”, tienen poco o nada en común. Cada uno tiene trampas de las que debe estar consciente. Algunos son bien conocidos; otros son más encubiertos.

Además, el hecho de que la modernización signifique tantas cosas diferentes es en sí mismo particularmente molesto: antes de que pueda modernizar una aplicación determinada, primero debe decidir, no solo si debe modernizarla, sino qué tipo de modernización necesita.

Luego, multiplique por la cantidad de aplicaciones en su cartera.

2. La actualización de la versión es su propia forma de endeudamiento

Algunos equipos de liderazgo de TI piensan que están siendo expertos en negocios al “no comprar tecnología por el bien de la tecnología” y, para apilar un cliché sobre otro, adoptar un enfoque de “si no está roto, no lo arregle” para administrar aplicaciones y las pilas en las que se ejecutan.

Aplican esta lógica a las aplicaciones comerciales y a todas las plataformas en las que se ejecuta cada aplicación: el sistema operativo del servidor, DBMS, CMS, entorno de desarrollo, sistema operativo de escritorio, navegador, etc.

Desafortunadamente, la Ley de Pagarlo ahora o Pagarlo después todavía prevalece: Pagarlo después invariablemente cuesta más y es más perjudicial que mantenerse al día.

3. Replataformar resuelve sólo una variable

Mover las aplicaciones heredadas a un entorno abierto que tenga las plataformas correspondientes hasta el final de la pila es otro enfoque de modernización popular, con una trampa no tan secreta. Reemplazar significa migrar de z / OS + COBOL + CICS + DB2 alojado en mainframe a Linux + COBOL + CICS + DB2 alojado en x85, por ejemplo. En las migraciones a la nube, esto se denomina “elevación y cambio”.

Esto es lo que obtiene: tarifas reducidas de licencia y soporte de proveedores. ¿El oscuro secreto? Eso es todo lo que obtienes.

4. El reemplazo de la plataforma cuesta más

El reemplazo de plataforma es un método de modernización que cambia sólo una plataforma en la que se ejecuta una aplicación, con el argumento de que es obsoleta o está perdiendo participación de mercado y participación de la mente. Por ejemplo, puede cambiar el DBMS de una aplicación de Sybase a SQL Server. Si bien esto a veces también se llama “reestructuración”, no tiene nada en común con la reestructuración como se describe anteriormente.

Lo que obtiene: menos riesgos y vulnerabilidades que provienen del uso de tecnología obsoleta; también, acceso a un mejor grupo de talentos. Lo que no obtiene: costos reducidos o capacidades mejoradas. De hecho, los costos aumentarán porque tendrá que obtener la licencia de la plataforma de reemplazo.

5. La modernización del idioma a menudo empeora una mala situación

El atractivo argumento de venta dice que las herramientas automatizadas extraerán la lógica de su negocio de su código COBOL heredado y lo reescribirán en un lenguaje moderno. Esto a menudo se logra reemplazando, digamos, una aplicación COBOL de 100,000 líneas de código por una aplicación Java de 100,000 líneas de código.

Ese es el secreto más oscuro de la modernización del lenguaje: los idiomas no son sólo vocabulario y sintaxis. Los idiomas traen consigo filosofías de diseño de aplicaciones.

El segundo secreto más oscuro: los lenguajes generalmente también traen consigo bibliotecas completas de lógica predesarrollada. Un equipo de desarrollo que escribe una nueva aplicación aprovecha estas bibliotecas. Pocos convertidores de código, si es que hay alguno, pueden hacer eso, lo que significa que el código convertido que generan es aún más difícil de mantener.

6. La refactorización realmente moderniza. Entonces, por supuesto, es costoso y requiere mucho tiempo

La refactorización es una técnica de modernización que convierte la estructura de una aplicación obsoleta para que se ajuste a prácticas comprobadas, por ejemplo, normalizar los datos o reestructurar el código monolítico en una arquitectura de microservicios.

Algunas herramientas pretenden automatizar gran parte de esta reestructuración. Por supuesto, pruébelos … en el níquel del proveedor hasta que unas pocas pruebas de concepto bien elegidas lo convenzan de que las herramientas funcionan como se anuncia.

También tenga cuidado: algunas versiones de refactorización automatizada conservan exactamente el comportamiento de la aplicación. Si bien esto minimiza la interrupción del negocio, no convierte una aplicación por lotes de la noche a la mañana en un procesamiento casi en tiempo real, el cambio de arquitectura que probablemente generará una ventaja competitiva.

La refactorización ofrece importantes beneficios comerciales en forma de adaptabilidad y flexibilidad mejoradas. Pero no existe el almuerzo gratis. En el caso de la refactorización, ni siquiera existe un almuerzo con el presupuesto de McDonald’s. La modernización de la arquitectura entrega los productos, pero es costosa y requiere mucho esfuerzo.

7. Es posible que la conversión COTS no parezca una técnica de modernización… pero lo es, y suele ser la mejor alternativa de modernización

A menudo, el mejor camino hacia una cartera de aplicaciones modernizada es reemplazar un “ecosistema” de aplicaciones del estado actual con un conjunto moderno de aplicaciones escritas por otra persona. Está lejos de ser una panacea: cualquiera que haya estado involucrado en la conversión a una suite COTS / SaaS sabe lo difícil que puede ser, pero a menudo es la forma menos arriesgada y más limpia de reemplazar una colección de aplicaciones cuyas plataformas y arquitectura son noticias de ayer para algo. que tiene futuro y puede ayudar a la empresa a alcanzar el futuro planificado.

8. Saber lo que se tiene requiere más transpiración que la automatización

Ahora que hemos analizado los oscuros secretos de los distintos métodos de modernización que elija, hay algo más fundamental de lo que debe tener cuidado. Antes de que pueda modernizar una aplicación, debe saber que la tiene y cómo está construida para saber cuál de los tipos de modernización que acabamos de comentar podría ser aplicable.

Lamentablemente, a pesar de todas las promesas hechas por todos los brillantes proveedores de brillantes herramientas de descubrimiento automatizado, estas herramientas sólo son útiles para descubrir servidores y no cuáles aplicaciones se ejecutan en ellos.

Lo que hace que las luces sean aún más tenues es que si la documentación del inventario de su aplicación es tan incompleta que necesite el descubrimiento automático y no haber documentado las plataformas: el entorno de desarrollo, el sistema operativo del servidor, el DBMS, el sistema de administración de contenido y otras herramientas en las que se ejecuta cada aplicación. Hasta que no sepa esto, no podrá comenzar a elegir cuál de las modernizaciones mencionadas anteriormente proporcionará el mayor beneficio.

9. El software es una opinión, lo que hace que la integración de aplicaciones sea un argumento

Cada aplicación empresarial codifica la opinión de un equipo de desarrollo sobre cómo debería funcionar algún aspecto de la organización. La sintaxis de su opinión está escrita en código. Su vocabulario está cincelado en el diseño de datos de la aplicación.

Cuando el alcance de dos o más aplicaciones se superpone, cuando, para tomar un ejemplo simple, los sistemas de cuentas por cobrar y CRM mantienen los datos del cliente, se necesita automatización para mantener los dos conjuntos de registros sincronizados. Sume todas las superposiciones de aplicaciones en una cartera y el resultado puede ser cientos de programas de interfaz punto a punto personalizados, todos los cuales deben modificarse y probarse por regresión cada vez que un equipo de desarrollo agrega o modifica una aplicación.

Un bus de servicio empresarial (ESB) o tecnología similar puede ayudar a reducir la gran cantidad de interfaces que definen una interfaz única para cada aplicación.

Pero además de la gran cantidad de interfaces, existe el problema de las desalineaciones semánticas, es decir, sus cuentas por cobrar y los modelos de datos de clientes de los sistemas CRM son diferentes. Conciliar estas diferentes definiciones de la misma entidad es lo que hace que la integración sea complicada al principio y más complicada de mantener.

Un ESB no puede solucionar el problema de las diferentes semánticas porque el problema no es tecnológico en primer lugar. Es que los desarrolladores no están de acuerdo.

10. Modernizar la fuerza de trabajo de TI suele ser más difícil que modernizar las aplicaciones que admiten

Su fuerza laboral es, presumiblemente, muy competente para mantener y mejorar las aplicaciones y las plataformas subyacentes que componen su arquitectura de aplicaciones actual. También son un depósito de conocimiento profundo sobre cómo se utilizan sus aplicaciones para que la empresa funcione como se supone que debe funcionar.

No son muy competentes en las aplicaciones y plataformas de reemplazo que implementará su plan de modernización.

Necesitará que sean tan competentes en los reemplazos como lo son ahora si su plan de modernización va a funcionar.

Más allá de eso, usted necesitará que se vuelvan competentes para que puedan detectar las oportunidades de mejora empresarial que sólo pueden provenir de personas inteligentes que estén familiarizadas tanto con las herramientas disponibles como con la situación actual.

El oscuro secreto: mostrarles la puerta y contratar reemplazos simplemente no funciona.

Seguro, puede darles de baja. Pero encontrar reemplazos competentes no será barato ni fácil, y no importa cuán competentes resulten ser sus reemplazos, la regla general es que reemplazar a un empleado cuesta el equivalente al salario de un año; sería prohibitivamente caro.

Cuál es una razón más por la que el último secreto oscuro del mod de la aplicación es el peor secreto oscuro…

11. Las organizaciones de TI bien administradas rara vez necesitan modernizarse

Las organizaciones de TI bien gestionadas practican la gestión del ciclo de vida. Mantienen todo actualizado todo el tiempo. Esto mantiene el presupuesto manejable: el esfuerzo de modificación de la aplicación es constante con pocas iniciativas “big bang” y tiene el feliz beneficio adicional de mantener su fuerza de trabajo modernizada junto con sus aplicaciones y plataformas.

Bob Lewis, CIO.com