Dos días, un ingeniero, cero conjeturas: simplificación de una modernización compleja con IBM Bob

En el otoño de 2025, la consultora de TI Novacomp asumió una actualización desafiante para sus operaciones internas: modernizar una API REST de Java crítica para el negocio sin interrumpir la lógica comercial existente. Es el tipo de proyecto que un equipo de Novacomp de tres a cinco personas tardaría un par de meses en completar: buscar dependencias obsoletas, realizar manualmente actualizaciones complejas, todo mientras se gestiona la exposición de seguridad y se preservan todos los comportamientos y contratos subyacentes.

Como IBM Partner, Novacomp formó parte de la vista previa de IBM Bob, el entorno de desarrollo integrado (IDE) basado en IA de IBM. La empresa decidió probar IBM Bob como parte de su iniciativa interna de modernización.

Los resultados fueron impresionantes. Mediante el uso de IBM Bob, un arquitecto sénior de soluciones y defensor de IBM 2026 (Jorge De Trinidad de Novacomp) completó la compleja actualización en dos días. El resultado fue aproximadamente un 98 % más rápido de lo que normalmente se requeriría con un equipo más grande. Novacomp informa que IBM Bob es mucho más que un generador de código. Ofrece un análisis contextual y detallado del código fuente, sugiere de forma proactiva mejoras y actualizaciones estructurales, e incluso traza hojas de ruta para futuras opciones de actualización.

En esta publicación, analizaremos el caso de uso principal, los detalles de la arquitectura que IBM Bob modernizó y los beneficios que IBM Bob aportó a Novacomp y a su cliente.

El principal caso de uso para este proyecto cliente de Novacomp fue una actualización estructural: cambiar la plataforma de un monolito lógico en capas para habilitar una arquitectura de microservicios nativa de la nube. Las aplicaciones consisten en API REST empresariales escritas con versiones anteriores de Java y árboles de dependencia heredados que eran cada vez más costosos de mantener y difíciles de proteger.

Los consumidores de la API eran equipos de ingeniería en contextos de infraestructura de TI, incluidos equipos que trabajaban en un entorno de captura de datos de cambio (CDC). Esta herramienta monitorea las replicaciones de la tecnología de IBM y expone las API utilizadas por los stakeholders internos. 

Al tratarse de API críticas para el negocio, el equipo de Novacomp se enfrentó al desafío de la preservación funcional estricta. Necesitaban mantener estables la lógica empresarial y los contratos de API mientras actualizaban la arquitectura.

Antes de la modernización, la arquitectura de referencia era un servicio Java en capas: controladores REST, una capa de servicio y repositorios API de persistencia Java (JPA) respaldados por una base de datos relacional con gestión de dependencias manejada a través de Maven o Gradle (consulte el diagrama que se presenta a continuación).

Como impulsor fundamental de la modernización, IBM Bob fue más que un generador de código; fue un asistente compatible con repositorios integrado en un bucle de validación de ingeniería. Las recomendaciones de Bob debían ser conscientes del contexto de la base de código existente, tener alta explicabilidad para sus recomendaciones técnicas y ofrecer oportunidades a los ingenieros para validarlas y perfeccionarlas.

En esencia, IBM Bob necesitaba actuar como un “amplificador cognitivo” en lugar de un reemplazo para las decisiones de los desarrolladores. Por ejemplo, durante la actualización de las versiones de Java y Spring Boot, IBM Bob revisó la estructura del código, la configuración y las dependencias para proponer cambios incrementales basados en el código.

Identificaba y explicaba anotaciones obsoletas, posibles cambios rompientes entre versiones del marco y ofrecía un análisis completo de dependencias antes de actualizar. Si bien Bob validó continuamente los cambios con compilaciones limpias y resolución de conflictos de dependencia, incluyó a humanos en el ciclo al detenerse para la revisión arquitectónica. Su documentación de cambios rastreable actuó como criterio de aceptación antes de que los ingenieros aprobaran la fusión de cambios.

Después de la modernización, la arquitectura seguía estando en capas, pero se volvió estructuralmente más limpia y preparada para el futuro: Java actualizado (Java 17 a Java 21 LTS),Spring Boot moderno, un árbol de dependencias consolidado y validado y configuraciones refactorizadas alineadas con las prácticas nativas de la nube actuales. Se eliminaron las anotaciones obsoletas y los patrones heredados, se eliminaron las bibliotecas vulnerables y la arquitectura se alineó mejor con los modelos de despliegue modernos y fue compatible con la contenerización.

El valor de IBM Bob en este escenario se mostró de cuatro maneras prácticas:

• Orientaciones sobre modernización relacionadas con el código fuente. IBM Bob recomendó actualizaciones no solo para Java, sino también para otras herramientas comúnmente utilizadas en el sistema Java, incluidas Maven, Gradle y Spring Boot.
• Análisis de impacto sin semanas de arqueología manual. El flujo de trabajo pasó de las actualizaciones de prueba y error a un proceso más gobernado que presenta cambios importantes, interacciones de dependencia transitivas y cambios sutiles de configuración antes.
• Modernización de la documentación y las pruebas como parte del cambio. El esfuerzo de modernización incluyó la generación de documentación actualizada y la renovación de casos de prueba para que coincidieran con la pila actualizada.
• Reducción de riesgos que los ingenieros pueden defender. Aunque las cifras de CVE no fueran el tema principal, la migración en sí misma entrañaba riesgos, sobre todo en lo que respecta a los cambios en el marco y la adaptación de las dependencias. IBM Bob redujo ese riesgo al hacer que los cambios fueran más sistemáticos y revisables.

Varios resultados de este proyecto de modernización son importantes para los líderes de ingeniería, ya que se correlacionan directamente con el costo, el riesgo y la previsibilidad de la entrega:

• Ciclos de modernización más rápidos con menos sorpresas. Convertir “meses” en “días” cambia la forma en que se pueden programar y gobernar las actualizaciones, especialmente cuando la alternativa es un trabajo de larga duración que bloquea a los equipos e infla los costos de coordinación.
• Menor riesgo operativo durante la migración. La posibilidad de que las actualizaciones manuales introdujeran regresiones o problemas de seguridad y estabilidad posteriores en la producción se redujo considerablemente.
• Una mejor experiencia para los desarrolladores gracias a la estructura y la documentación. Los sistemas heredados a menudo sobreviven a los equipos que los construyeron. El flujo de trabajo de modernización generó una documentación clara y un registro de cambios atómicos incrementales, lo que respalda un flujo de trabajo que equilibra la evolución rápida con la mitigación de riesgos.
• Capturas concretas y reales. Un ejemplo que salió a la superficie durante el análisis fue una variable que no realizó su trabajo previsto, el tipo de problema sutil que puede persistir durante años porque se esconde dentro del código “de trabajo”.
• Una cobertura más integral. Muchos agentes de programación de IA pueden escribir código, pero carecen del contexto esencial para la modernización. Sin embargo, IBM Bob es consciente de las dependencias, configuraciones, pruebas e impactos descendentes.

IBM Bob también proporcionó a Novacomp un conjunto de recomendaciones sobre cómo abordar varias rutas para actualizar de versiones antiguas a nuevas (microservicios frente a un método más “tradicional”, por ejemplo). Este enfoque permitió la creación de una hoja de ruta transformadora, con IBM Bob como guía que justifica sus recomendaciones.

Más allá del papel desempeñado por IBM Bob en este proyecto concreto de refactorización, el descubrimiento de un método de modernización repetible tuvo un impacto significativo para Novacomp. IBM Bob permite utilizar la IA para identificar desde el principio las relaciones de dependencia y los aspectos de configuración, mantener a las personas al mando de las decisiones arquitectónicas y considerar la documentación, las pruebas y la gobernanza como resultados, no como elementos secundarios.

Esa repetibilidad es lo que hace que el enfoque sea escalable para un modelo de consultoría. El mismo flujo de trabajo se puede aplicar como evaluación preventiva antes de actualizaciones importantes, como parte de la revisión de solicitudes de extracción para evitar cambios bruscos y la acumulación de deuda técnica antes en el proceso de desarrollo.

También admite diferentes movimientos de entrega. Puede cubrir la entrega de “fábrica de software” donde el trabajo se realiza dentro de un entorno controlado y el aumento de personal donde los clientes adoptan licencias para que los equipos conjuntos puedan colaborar con herramientas y gobierno consistentes.

Al basarse en IBM Bob como una capa de modernización centrada en la IA, Novacomp convirtió una compleja actualización de Java y Spring Boot de alto riesgo en una práctica de ingeniería gobernada y repetible. Esta práctica ayuda a reducir el riesgo de migración, mejora la capacidad de mantenimiento y facilita que los equipos evolucionen los servicios críticos sin reconstruir la base cada vez.

Explore una prueba gratuita para ver cómo los desarrolladores crean código de calidad más rápido 

Regístrese para el seminario web