Cómo reducir los tiempos y costos de migración de sistemas legados con IA

El 42% del tiempo de los equipos de desarrollo se destina a gestionar deuda técnica, según The Developer Coefficient, el informe de la plataforma financiera Stripe que analiza la eficiencia de la ingeniería de software y su impacto global. Esto es, no se ocupa de construir nuevas funcionalidades, sino de resolver problemas acumulados en sistemas existentes. En términos de inversión, esto representa unos 85.000 millones de dólares anuales destinados a sostener lo que ya existe, de acuerdo con este mismo reporte.

El dilema es bien conocido por las organizaciones: el Global Technology Executive Survey, de la consultora global Protiviti, plantea que el 70% de las empresas declara que su deuda técnica le impide innovar y, sin embargo, el mismo informe desglosa que estas organizaciones destinan el 30% de su presupuesto a mantener dicha deuda.

Podría interpretarse como una decisión equivocada; en redbee consideramos que no lo es: con las condiciones previas del mercado, invertir por encima de ese presupuesto no generaba retorno suficiente. El problema no tenía solución, estaba fuera de escala.

Por qué se abandonan los proyectos de modernización

Cuando una organización identifica un sistema que limita la evolución del negocio, la conversación suele derivar hacia uno de dos caminos. El primero: "Es muy costoso, lo postergamos para el próximo año". El resultado es predecible: el año siguiente el problema persiste, agravado, porque el sistema legado siguió creciendo y las vulnerabilidades y las funcionalidades pendientes son aún más difíciles de abordar.

El segundo camino: "Avancemos, pero con la mitad del tiempo y el presupuesto". El resultado es igualmente predecible: el proyecto se vuelve inviable. Y, con frecuencia, ambos caminos se encadenan: se posponen hasta que la urgencia obliga a actuar y, entonces, se ejecuta bajo presión.

No existe una fórmula secreta: existe un método

Nuestra visión propone una secuencia de cinco fases que permite asegurar la calidad de extremo a extremo. Estas fases están compuestas de prácticas de ingeniería adoptadas en la industria:

• Descubrimiento ("Discovery"). Comprender la composición del sistema legado. El resultado es un documento disponible para todo el equipo de ingeniería.
• Evaluación ("Assessment". Elaborar un caso de negocio para determinar si la migración es viable. En esta instancia se toma una decisión: migrar lo existente o construir un sistema paralelo y descartar el legado.
• Diseño de estrategias ("Strategy design"). Definir el enfoque de migración en función del contexto específico del cliente.
• ADR (sigla en inglés por registros de decisiones de arquitectura). Documentar la transición del estado actual hacia la arquitectura propuesta.
• Funciones de aptitud física ("Fitness functions"). Un conjunto de test y métricas que verifican de forma continua que la arquitectura se comporta conforme a lo esperado.

De dos meses a 40 minutos

Hasta hace pocos meses, recorrer esas cinco fases demandaba más de dos meses de trabajo con un equipo de ingenieros. Hoy, con un agente y un único ingeniero, el proceso insume aproximadamente 40 minutos.

Esto incide directamente en la contradicción señalada al inicio. Cuando estos proyectos se extendían en el tiempo, se producían dos consecuencias recurrentes: se abandonaban o se comprimían. Y cuando ocurría esto último, lo primero que se resignaba era precisamente lo que garantiza la calidad: las fitness functions quedaban sin implementarse, la documentación de arquitectura y los ADR permanecían incompletos, y las decisiones se tomaban sin un proceso de discovery riguroso como respaldo. Cuando ese proceso puede completarse en 40 minutos, la ecuación se transforma.

¿Qué cambió realmente?

Cuando hacemos estas afirmaciones no nos basamos en nada nuevo: son herramientas de ingeniería con años de trayectoria, y lo que un ingeniero realiza hoy mediante un agente es, en esencia, lo que antes ejecutaba en colaboración con otros ingenieros. Lo que cambió es el tiempo: proyectos que antes demandaban meses o años, y que en muchos casos eran inviables para el negocio por el esfuerzo que requerían, hoy los resolvemos con entre un 50% y un 60% de mayor rapidez y eficiencia.

El método es agnóstico a la tecnología. La única condición verdaderamente determinante son las pruebas ("testing"); cuando el sistema legado carece de él, el primer paso, ahora que existe margen para hacerlo, es construir una capa de tests con el sistema original aún en funcionamiento, para garantizar que, al reemplazarlo, el comportamiento se preserve.

Para dimensionarlo en términos de negocio, un proyecto de esta naturaleza reduce el esfuerzo a la mitad, lo cual no representa únicamente un ahorro: significa demostrar valor antes, y redirigir la inversión hacia iniciativas que generan impacto real en los resultados del negocio, en lugar de destinarla a resolver deuda acumulada.

(*) Jefe de ingeniería de redbee.