Un dato motiva gran parte del trabajo que realizamos en redbee: el 42% del tiempo de los equipos de desarrollo se destina a gestionar deuda técnica*1. No a construir nuevas funcionalidades, sino a resolver problemas acumulados en sistemas existentes. En términos de inversión, esto representa unos 85.000 millones*2 de dólares anuales destinados a sostener lo que ya existe . La paradoja es conocida: el 70% de las empresas declara que su deuda técnica le impide innovar *3 y, sin embargo, destina el 30% de su presupuesto a mantenerla*4. 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 umbral no generaba retorno suficiente. El problema hasta entonces 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. Ninguno de los dos produce resultados que solucionen el problema del negocio.

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

En redbee aplicamos una secuencia de cinco fases que permite asegurar la calidad de extremo a extremo, cabe destacar que estas fases están compuestas de prácticas de ingeniería adoptadas en la industria:

1. Discovery. Comprender la composición del sistema legado: lenguajes, frameworks, arquitectura y, especialmente, la existencia de cobertura de testing. El resultado es un documento disponible para todo el equipo de ingeniería.

2. Assessment. Elaborar un business case para determinar si la migración es viable. Se miden el índice de acoplamiento y el de inconsistencia entre componentes, se construye una matriz de ponderación y se toma una decisión: migrar lo existente o construir un sistema paralelo y descartar el legado.

3. Strategy design. Definir el enfoque de migración. Existen tres estrategias canónicas: estrangulamiento (strangler pattern), separación por módulos y bifurcación del servicio para eliminar progresivamente lo que ya no se utiliza. La elección se realiza en función del contexto específico del cliente.

4. ADRs (Architecture Decision Records). Documentar, con la precisión de una user story técnica, la transición del estado actual hacia la arquitectura propuesta.

5. Fitness functions. Un conjunto de tests y métricas que verifican de forma continua que la arquitectura se comporta conforme a lo esperado.

De dos meses a cuarenta 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 sobre 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 se comprimían, 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 ADRs permanecían incompletos, y las decisiones se tomaban sin un proceso de discovery riguroso como respaldo. El tiempo no era un factor secundario: era el condicionante central del resultado. Cuando ese proceso puede completarse en 40 minutos, la ecuación se transforma.

¿Qué cambió realmente?

Si se analiza el conjunto, en redbee no hemos desarrollado prácticas nuevas. 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 entre un 50% y un 60% más rápido/eficiente.

El método es agnóstico a la tecnología: en redbee migramos sistemas en AS/400, Java o Scala sin que eso altere la mecánica del proceso. La única condición verdaderamente determinante es el 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 difícilmente se sitúe por debajo de los dos millones de dólares, y con frecuencia concluye sin completarse, con una parte del legado todavía operando. Reducir ese esfuerzo a la mitad 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. Esa es, en definitiva, la promesa concreta de este enfoque.

Fuentes:
*1-2 Stripe Developer Coefficient Report. – stripe.com/files/reports/the-developer-coefficient.pdf 

*3-4  Protiviti — Global Technology Executive Survey. www.protiviti.com/us-en/global-technologyexecutive-survey