La deuda técnica es uno de los retos más profundos —y menos visibles— que enfrentan hoy las organizaciones que operan con IBM i. No es solo un tema de código antiguo o tecnologías heredadas; es la suma de años de decisiones racionales, prioridades de negocio, presiones operativas y percepciones que moldearon la inversión (o falta de ella) en la plataforma. En nuestro webinar analizamos este fenómeno desde una perspectiva de negocio, buscando explicar no solo qué es la deuda técnica, sino por qué llegó a niveles tan críticos en muchos entornos IBM i.
Lo interesante es que esta deuda no se origina únicamente en empresas que intentaron migrar fuera del IBM i. Incluso aquellas que permanecieron fieles a la plataforma han acumulado complejidades arquitectónicas, procesos difíciles de mantener y una dependencia cada vez mayor de equipos con conocimiento histórico. En ambos casos, el origen es similar: durante muchos años la industria dejó de ver al IBM i como una tecnología con futuro claro, y esa pérdida de fe colectiva tuvo un impacto transversal en inversión, talento y evolución tecnológica.
Mientras analizábamos la historia reciente del IBM i, quedó claro que gran parte de la deuda técnica actual se gestó en la década de los 2000. No porque se tomaran malas decisiones, sino porque la industria estaba experimentando un cambio acelerado: internet, móviles, cloud, APIs y arquitecturas abiertas tomaron un protagonismo que parecía incompatible con un sistema sólido y estable, pero percibido como “lento” o “difícil de modernizar”. Con señales poco claras sobre la evolución de la plataforma, era lógico que las empresas priorizaran inversiones en tecnologías emergentes.
Ese desplazamiento de atención no significó abandonar el IBM i, pero sí frenó la inversión estructural en él. Durante años, se aprobaban gastos operativos para mantener el sistema funcionando, pero no proyectos estratégicos para evolucionarlo. Al mismo tiempo, las universidades dejaron de enseñar RPG o COBOL, el talento joven se fue hacia tecnologías de moda y la percepción de “sistema viejo” se convirtió en una narrativa dominante. El resultado fue un ecosistema donde la plataforma seguía siendo crítica para el negocio, pero estaba cada vez más aislada en términos de inversión, talento y visibilidad directiva.
Uno de los puntos clave del webinar fue entender cómo la deuda técnica crece cuando una organización opera exclusivamente en modo reactivo. En lugar de evaluar decisiones desde el retorno de inversión, muchas áreas comenzaron a priorizar resolver urgencias: auditorías, parches, integraciones improvisadas, ajustes manuales o procesos de alto riesgo que no podían fallar. Este enfoque resolvía problemas inmediatos, pero dejaba intactas las causas de fondo.
Lo que se generó fue un círculo vicioso: al no invertir en la evolución del IBM i, el sistema se volvió más rígido; al volverse más rígido, cada cambio costaba más; al costar más, la organización evitaba invertir en mejoras estructurales; y así, la deuda técnica seguía creciendo silenciosamente. En muchos casos, esto llevó a estructuras complejas, dependencias de personas clave, bases de datos sin normalizar y programas difíciles de modernizar.
Para explicar este fenómeno de forma visual, utilizamos la metáfora del Tetris. El negocio nunca se detiene: siempre caen nuevas piezas, ya sean regulaciones, integraciones, productos nuevos o auditorías. Cuando el tablero está ordenado, las piezas encajan bien. Pero cuando el sistema acumula huecos —parches, lógica duplicada, bases de datos antiguas, procesos dependientes de pantallas verdes— cada pieza cae peor, ocupa más espacio y hace más difícil acomodar la siguiente.
Lo importante es que, igual que en Tetris, un sistema no colapsa por una sola pieza mal acomodada. Colapsa por acumulación. Esa acumulación es la esencia de la deuda técnica.
El webinar cerró con un mensaje claro: modernizar no es una iniciativa técnica, sino una decisión estratégica que impacta directamente en riesgo, continuidad operativa, agilidad e innovación. No se trata de reemplazar el IBM i ni de adoptar una moda tecnológica, sino de liberar espacio en el tablero. Modernizar bases de datos, reorganizar arquitectura, refactorizar código crítico, documentar procesos y formar talento nuevo son pasos fundamentales para evitar que la deuda técnica siga creciendo.
Si el IBM i seguirá siendo un pilar del negocio —como lo es en la mayoría de organizaciones— entonces merece una estrategia clara de modernización. La deuda técnica no desaparece con el tiempo. Por el contrario, crece. Y la diferencia entre sobrevivir y evolucionar está en enfrentarla antes de que el tablero se llene por completo.
