Durante años, la narrativa ha sido la misma: el problema del mainframe está en el lenguaje, en el legado, en la dificultad para evolucionar. En la práctica, el bloqueo más crítico está en otro lugar: el entorno.

En z/OS, múltiples equipos aún compiten por el mismo espacio de pruebas. Esto genera un efecto predecible —y costoso—: cambios que interfieren entre squads, ciclos de QA comprometidos, retrabajo constante y colas de proyectos que impiden el paralelismo.

El resultado no es técnico, es operativo. Sprints que deberían durar semanas se extienden por meses. En algunos casos, casi un año.

El costo invisible del entorno compartido

Este modelo no solo desacelera, sino que drena eficiencia sin aparecer claramente en el presupuesto. Cada dependencia de infraestructura, cada ticket abierto, cada ajuste manual incrementa el tiempo de entrega y el costo por entrega.

Sin aislamiento, el desarrollo en mainframe se vuelve lineal por definición. Si dos proyectos no pueden probarse al mismo tiempo, la innovación entra en cola. Y en entornos críticos, la cola es costo acumulado.

Para romper este ciclo, no basta con optimizar procesos. Es necesario cambiar el modelo. La solución ya no es una herramienta adicional, sino un cambio arquitectónico.

Con Eccox APT (Application for Parallel Testing), el entorno deja de ser compartido y pasa a ser aislado por diseño. Cada squad opera en su propia “pista”, con instancias aisladas de CICS, IMS, MQ y Db2, datos independientes y ejecución paralela sin colisiones.

A diferencia de soluciones de emulación, todo ocurre sobre el propio z/OS, con un comportamiento idéntico al entorno de producción, preservando la integridad de las operaciones y de las cadenas de procesamiento.

Otro punto crítico desaparece junto con el entorno compartido: la dependencia de infraestructura. Con provisión vía interfaz web y un modelo self-service, el desarrollador puede crear su entorno bajo demanda, sin depender de tickets ni esperar semanas por configuraciones.

El tiempo deja de ser un factor externo y vuelve a estar bajo el control del equipo.

Qué cambia en la práctica

En el modelo tradicional, la provisión de entornos puede tardar hasta cuatro semanas, los ciclos de validación son largos y el paralelismo es prácticamente inexistente.

Con aislamiento real, la provisión puede realizarse en aproximadamente dos horas, múltiples flujos operan simultáneamente y los ciclos de sprint se reducen de forma significativa.

Lo que antes llevaba meses puede reducirse en aproximadamente un 43% en el ciclo de sprints, dependiendo del contexto operativo.

El aumento del volumen transaccional —impulsado por mobile y PIX— ya ha incrementado el consumo de infraestructura en cerca de un 35%, sin generar ingresos proporcionales. Esto cambia completamente la ecuación.

Ya no se trata solo de entregar más rápido, sino de evitar que el costo operativo crezca de forma descontrolada. Los entornos ineficientes dejan de ser un problema de productividad y pasan a ser un problema financiero, especialmente con la modernización a través de Eccox APT, que entrega resultados concretos en entornos de alta complejidad.

Este modelo ya ha sido aplicado en operaciones a gran escala.

En Bradesco, durante el Proyecto BIN, el esfuerzo de provisión se redujo de 154 horas a 18,35 horas, mientras que el time-to-market cayó de 1.192 días a 146 días, una reducción del 88%.

En Itaú, el tiempo de provisión pasó de 480 horas a solo 2 horas, con una reducción del 60% en el tiempo de pruebas y una mejora del 25% en el time-to-market.

No se trata de una mejora incremental, sino de un cambio estructural en la forma de operar.

El impacto que no aparece en los gráficos

Cuando el entorno deja de ser un cuello de botella, el mainframe deja de percibirse como una limitación. Desarrolladores fuera del mundo legado, como profesionales de Java y Python, pueden operar en z/OS con autonomía.

El flujo deja de depender de conocimientos altamente especializados y pasa a acompañar el ritmo del negocio.

La discusión sobre la modernización del mainframe aún suele plantearse como una elección entre mantener o sustituir. En la práctica, esa ya no es la decisión relevante.

Lo que define la eficiencia hoy es cuánto el entorno permite evolucionar sin fricción. Cuando el cuello de botella desaparece, el mainframe deja de ser el problema y vuelve a ser el activo.

Reducir sprints de meses a días no es una ambición ágil, sino una respuesta directa a un modelo operativo que ya no se sostiene. Para los líderes de TI, el punto crítico no es solo acelerar el desarrollo, sino eliminar aquello que impide que ocurra al ritmo necesario.

Si reducir el ciclo de sprints es hoy una prioridad estratégica, vale la pena revisar qué está limitando tu operación. Habla con Eccox y descubre cómo aplicar este modelo en tu entorno.