[04/08/2021] Más del 95% de las empresas de la lista Fortune 1000 siguen utilizando IMS, el antiguo DBMS jerárquico de IBM. Al menos, esa es la cifra según TwoBitHistory.org.
Mi propia encuesta informal, en cambio, revela que aproximadamente el cero por ciento de los mejores desarrolladores de TI tienen algún interés en trabajar en ese entorno.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
La capacidad de atraer a los mejores talentos es una de las razones -no la única, pero sí una de las más importantes- para que los CIO modernicen su cartera de aplicaciones. Otras son la reducción de los costos de licencia y soporte, y la mejora de la flexibilidad y la adaptabilidad.
Pero la "modernización" no es una propuesta tan sencilla como podría parecer. Tiene oscuros secretos que los CIOs deben tener en cuenta en su toma de decisiones.
1. La modernización de las aplicaciones es un problema compuesto
La modernización de las aplicaciones abarca un montón de soluciones muy diferentes para un montón de problemas muy diferentes.
Dependiendo de la aplicación y de la persona con la que hable, la modernización de aplicaciones puede significar la actualización de la versión, la replanificación, la sustitución de la plataforma, la modernización del lenguaje, la refactorización o la conversión a COTS. Aunque todos ellos se denominan "modernización", tienen poco o nada en común. Cada una de ellas tiene escollos que hay que tener en cuenta. 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 modernizar una aplicación determinada, hay que decidir, no solo si hay que modernizarla, sino qué tipo de modernización necesita.
A continuación, multiplique por el número de aplicaciones de su cartera.
2. La actualización de versiones es su propia forma de deuda
Algunos equipos de liderazgo de TI piensan que están siendo inteligentes en los negocios al "no comprar tecnología por la tecnología" y, para apilar un cliché sobre otro, adoptando un enfoque de "si no está roto, no lo arregles" para gestionar las 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 ejecutan las aplicaciones (el sistema operativo del servidor, el sistema de gestión de bases de datos, el sistema de gestión de contenidos, el entorno de desarrollo, el sistema operativo de escritorio, el navegador, etc.) y solo las actualizan cuando las nuevas características específicas ofrecen un nuevo rendimiento de la inversión.
Desgraciadamente, la ley de pagar ahora o pagar después sigue vigente: pagar después siempre cuesta más y es más perjudicial que estar al día.
3. La replanificación solo resuelve una variable
Trasladar las aplicaciones heredadas a un entorno abierto con sus correspondientes plataformas a lo largo de toda la pila es otro enfoque de modernización popular, con un inconveniente no tan secreto.
Replatforming (cambiar de plataforma) significa migrar de mainframe alojado en z/OS + COBOL + CICS + DB2 a x85 alojado en Linux + COBOL + CICS + DB2, por ejemplo. En las migraciones a la nube, esto se llama "lift-and-shift".
Esto es lo que se consigue: reducir las tarifas de licencia y de soporte del proveedor. ¿El oscuro secreto? Eso es todo lo que obtiene.
4. La sustitución de la plataforma cuesta más
El reemplazo de la plataforma es un método de modernización que cambia solo una plataforma en la que se ejecuta una aplicación, con el argumento de que está obsoleta o está perdiendo cuota de mercado y de opinión. Por ejemplo, se puede cambiar el DBMS de una aplicación de Sybase a SQL Server. Aunque esto también se denomina a veces "replanificación", no tiene nada en común con la replanificación descrita anteriormente.
Lo que se obtiene: menos riesgos y vulnerabilidades que se derivan del uso de tecnología obsoleta; también, acceso a una mejor reserva de talento. Lo que no se consigue: Reducción de costos o mejora de las capacidades. Los costos, de hecho, aumentarán porque tendrás que adquirir la licencia de la plataforma de sustitución.
5. La modernización lingüística a menudo empeora una mala situación
El seductor argumento de venta dice que las herramientas automatizadas extraerán la lógica empresarial de su código COBOL heredado y la reescribirán en un lenguaje moderno. Esto se suele conseguir sustituyendo, por ejemplo, una aplicación COBOL de 100 mil líneas de código por una aplicación Java de 100 mil líneas de código.
Ese es el secreto más oscuro de la modernización de los lenguajes: Los lenguajes no son solo vocabulario y sintaxis. Los lenguajes traen consigo filosofías de diseño de aplicaciones.
El segundo secreto más oscuro: los lenguajes suelen traer consigo bibliotecas enteras 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 moderniza de verdad. Así que, por supuesto, es costoso y lleva 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 las prácticas probadas: normalizar los datos, por ejemplo, o reestructurar el código monolítico a una arquitectura de microservicios.
Algunas herramientas pretenden automatizar gran parte de esta reestructuración. Por supuesto, pruébelas... a costa del proveedor hasta que unas cuantas pruebas de concepto bien elegidas le convenzan de que las herramientas funcionan como se anuncian.
También hay que tener cuidado: Algunas versiones de la refactorización automatizada conservan exactamente el comportamiento de la aplicación. Aunque esto minimiza la interrupción del negocio, no convierte una aplicación de lotes de una noche a otra en un procesamiento casi en tiempo real, el cambio arquitectónico que más probablemente impulsará la ventaja competitiva.
La refactorización ofrece un gran beneficio empresarial en forma de mayor adaptabilidad y flexibilidad. Pero no existe el almuerzo gratis. En el caso de la refactorización, ni siquiera existe un almuerzo a precio de McDonald's. La modernización de la arquitectura proporciona los bienes, pero es cara y requiere mucho esfuerzo.
7. La conversión a COTS puede no parecer una técnica de modernización... pero lo es, y a menudo es la mejor alternativa de modernización
A menudo, el mejor camino hacia una cartera de aplicaciones modernizada es sustituir un "ecosistema" de aplicaciones actual por un conjunto moderno de aplicaciones escritas por otra persona. No es ni mucho menos una panacea -cualquiera que haya participado 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 sustituir una colección de aplicaciones cuyas plataformas y arquitectura son de ayer, por algo que tiene futuro y puede ayudar a la empresa a alcanzar su futuro previsto.
8. Saber lo que se tiene requiere más transpiración que automatización
Ahora que hemos repasado los oscuros secretos de los distintos métodos de modernización que ha elegido, hay algo más fundamental con lo que hay que tener cuidado. Antes de que pueda modernizar una aplicación, necesita saber que la tiene y cómo está construida, para saber cuál de los tipos de modernización que acabamos de discutir puede ser aplicable.
Lamentablemente, a pesar de todas las brillantes promesas hechas por todos los brillantes proveedores de brillantes herramientas de descubrimiento automatizado, estas herramientas solo son útiles para descubrir servidores, no qué aplicaciones se ejecutan en ellos.
Lo que hace que las luces se vuelvan aún más tenues es que si la documentación de su inventario de aplicaciones es tan incompleta como para necesitar el descubrimiento automático, es lo suficientemente incompleta como para no haber documentado las plataformas -el entorno de desarrollo, el sistema operativo del servidor, el DBMS, el sistema de gestión de contenidos y otras herramientas- en las que se ejecuta cada aplicación. Hasta que no sepa esto, no podrá empezar a elegir cuál de las modernizaciones comentadas anteriormente le aportará más beneficios.
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 ámbito de dos o más aplicaciones se solapa -cuando, por poner un ejemplo sencillo, los sistemas de cuentas por cobrar y de CRM mantienen ambos los datos de los clientes-, la automatización es necesaria para mantener los dos conjuntos de registros sincronizados. Si se suman todos los solapamientos de aplicaciones en una cartera, el resultado puede ser cientos de programas de interfaz personalizados punto a punto, que deben modificarse y someterse a pruebas de regresión cada vez que un equipo de desarrollo añade o altera una aplicación.
Un bus de servicios empresariales (ESB) o una tecnología similar puede ayudar a reducir el gran número de interfaces definiendo una única interfaz para cada aplicación.
Pero además del gran número de interfaces, existe el problema de los desajustes semánticos, es decir, los modelos de datos de clientes de sus sistemas de cuentas por cobrar y de CRM difieren. Conciliar estas diferentes definiciones de la misma entidad es lo que hace que la integración sea complicada al principio y más difícil de mantener.
Un ESB no puede solucionar el problema de las diferencias semánticas porque, en primer lugar, el problema no es tecnológico. Es que los desarrolladores no están de acuerdo.
10. Modernizar la plantilla de TI suele ser más difícil que modernizar las aplicaciones que soportan
Su personal es, presumiblemente, muy competente en el mantenimiento y la mejora de las aplicaciones y las plataformas subyacentes que componen su arquitectura de aplicaciones actual. También son un depósito de conocimientos profundos sobre cómo se utilizan sus aplicaciones para que el negocio funcione como se supone que debe hacerlo.
No son muy competentes en las aplicaciones y plataformas de reemplazo que su plan de modernización implementará.
Para que su plan de modernización funcione, necesitará que sean tan competentes en los reemplazos como lo son ahora.
Más allá de eso, necesitará que se vuelvan competentes para que sean capaces de detectar las oportunidades de mejora del negocio que solo pueden provenir de personas inteligentes que estén familiarizadas tanto con las herramientas disponibles como con la situación actual.
El <afortunadamente> oscuro secreto: no funciona el despedirlos y contratar sustitutos.
Por supuesto, se les puede despedir. Pero encontrar sustitutos competentes no será ni barato ni fácil, y por muy competentes que resulten ser sus sustitutos, la regla general es que sustituir a un empleado cuesta el equivalente a un año de salario: sería prohibitivo.
Lo cual es una razón más para que el último secreto oscuro de las aplicaciones sea el peor secreto oscuro...
11. Las organizaciones de TI bien gestionadas rara vez necesitan modernizarse
Las organizaciones de TI bien dirigidas 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.
Basado en el artículo de Bob Lewis (CIO) y editado por CIO Perú
Puede ver también: