El mercado ha consolidado una visión romantizada de la innovación en tecnología: un equipo guiado por una gran idea en busca de una aplicación. En las operaciones de misión crítica, la lógica se invierte. El problema surge primero; la ingeniería llega como respuesta.

La historia de Eccox comenzó así.

En 1992, la empresa nació a partir de un desafío técnico concreto: migrar sistemas de un equipo Honeywell Bull a un IBM Mainframe 4341, que por entonces operaba con MVS, predecesor de z/OS.

Los fundadores José Ronaldo Martins y Maurício da Costa e Silva organizaron la empresa en torno a una lógica que seguiría presente durante las décadas siguientes: investigar y desarrollar tecnología para resolver problemas que las herramientas disponibles no estaban solucionando.

El primer producto importante también siguió ese camino. SHAREVSAM surgió para abordar un problema específico de intercambio de datos entre el procesamiento online en CICS y el procesamiento batch. Más tarde llegaron otras iniciativas de I+D, incluidas soluciones de control de calidad para COBOL y SQL Db2.

Hay algo importante en esta historia: revela que la innovación va más allá de las funcionalidades de un software: su punto de partida está en los desafíos reales de la operación.

El usuario ve problemas que el laboratorio no puede reproducir

Quienes trabajan a diario con sistemas críticos conocen excepciones que difícilmente aparecen en una arquitectura diseñada sobre el papel.

Un proceso puede parecer técnicamente sencillo hasta encontrarse con cientos de dependencias. Un pequeño cambio puede competir por recursos con otro proyecto. Una prueba puede estar lista para ejecutarse, pero tener que esperar a que haya un entorno disponible. Una solución conceptualmente elegante puede volverse inviable cuando entran en juego la disponibilidad, los volúmenes transaccionales, la seguridad y décadas de integración.

Fue precisamente un problema de este tipo el que dio forma al ámbito en el que hoy actúa Eccox Application for Parallel Testing (APT).

En entornos mainframe, una respuesta tradicional a los conflictos entre proyectos consistía en replicar entornos o serializar las pruebas.

El problema es que replicar estructuras implica mantener versiones, sincronizar bases de datos, administrar infraestructura y consumir trabajo especializado. El resultado es un escenario en el que diferentes pruebas compiten por datos y entornos, con equipos dedicados a preparar y mantener esas estructuras.

La pregunta de ingeniería, entonces, no era simplemente “¿cómo crear otro entorno de pruebas?”. Era otra: ¿realmente es necesario reproducir todo el entorno para poder aislar aquello que ha cambiado?

APT parte de esta inversión de lógica. En lugar de replicar indiscriminadamente toda la infraestructura, permite crear pistas de prueba aislando los componentes necesarios para un escenario determinado, mientras los proyectos siguen utilizando la infraestructura real del mainframe.

La solución fue concebida para permitir pruebas en paralelo sin que las distintas ejecuciones interfieran entre sí.

Este tipo de respuesta difícilmente surge únicamente de la observación abstracta de una tendencia tecnológica. Surge cuando alguien convive durante suficiente tiempo con un problema como para darse cuenta de que la forma tradicional de resolverlo no tiene por qué ser la única.

Y esta lógica no es exclusiva de empresas más pequeñas o de productos especializados.

Cuando anunció el IBM z17, en abril de 2025, IBM informó que el sistema era el resultado de cinco años de diseño y desarrollo.

Durante ese período se presentaron más de 300 solicitudes de patente, pero hay otro dato igual de interesante: el z17 fue desarrollado con la participación directa de más de 100 clientes, en colaboración con los equipos de IBM Research y Software.

Es una combinación reveladora: cientos de invenciones, pero también cientos de conversaciones sobre lo que era necesario resolver.

Incluso una plataforma con la dimensión tecnológica de IBM Z no evoluciona únicamente a partir de la capacidad de los laboratorios para imaginar el futuro. Evoluciona en contacto con organizaciones que necesitan llevar la IA a producción, proteger datos, procesar volúmenes crecientes y mantener disponibles sus sistemas críticos.

El desarrollo tecnológico sigue exigiendo investigación profunda. Lo que cambia es el origen de las preguntas.

En lugar de abandonar la investigación, la I+D orientada a problemas la dirige hacia la resolución de desafíos reales.

En misión crítica, innovar también significa conocer el contexto

Este principio es especialmente relevante en el mainframe porque rara vez se parte de una hoja en blanco.

Las empresas están modernizando sistemas que ya están en funcionamiento, procesan operaciones reales y acumulan reglas construidas a lo largo de décadas. Por eso, una solución puede ser técnicamente sofisticada y aun así fracasar si exige que la organización abandone todo aquello que ya funciona para poder adoptarla.

En el caso de las pruebas, APT parte de la infraestructura existente. Los componentes necesarios para una determinada condición pueden clonarse y dirigirse a la pista correspondiente; los demás siguen utilizándose en el entorno original.

Es una diferencia de enfoque. En lugar de comenzar preguntando cómo trasladar el problema a una nueva arquitectura, se empieza preguntando qué es exactamente lo que está impidiendo al usuario trabajar mejor en la arquitectura que ya tiene.

Este tipo de pregunta explica buena parte de la trayectoria de Eccox. La empresa nació a partir de un proyecto de migración, creó su primer producto para resolver un problema operativo de procesamiento y continuó situando la I+D en el centro de su negocio.

Más de tres décadas después, las tecnologías son distintas y los problemas también, pero el método sigue siendo reconocible.

Escuchar al mercado no significa simplemente preguntarle qué quiere

Existe una diferencia entre el desarrollo orientado al usuario y el desarrollo por encargo.

El usuario no siempre sabe qué producto necesita. Lo que sí conoce profundamente es la dificultad a la que se enfrenta: dónde pierde tiempo, dónde surgen conflictos, dónde la operación depende de trabajo manual y dónde un cambio representa un riesgo.

Corresponde a la ingeniería transformar ese dolor en una solución que pueda repetirse, automatizarse y utilizarse en otras organizaciones.

Así surgieron muchas categorías de software. Primero existe un problema aparentemente particular. Después se descubre que otras empresas enfrentan la misma limitación. Cuando la solución deja de resolver un único caso y pasa a encapsular conocimiento para resolver toda una categoría de problemas, el proyecto comienza a convertirse en producto.

Este es el aspecto menos visible de la I+D en tecnología empresarial.

La patente, el algoritmo o la arquitectura aparecen al final. Antes de ellos, normalmente hay alguien diciendo: “de esta manera no está funcionando”.

Para Eccox, esta escucha siempre ha formado parte del proceso de ingeniería y sigue siendo especialmente relevante en un momento en el que el mainframe debe convivir con la nube, la IA, nuevas prácticas de desarrollo y expectativas cada vez mayores de velocidad, sin renunciar a la confiabilidad que sostiene las operaciones críticas.

Innovar en este mercado no significa perseguir cada novedad que aparece. Significa entender qué problemas realmente merecen una solución nueva.

APT es un ejemplo de esta trayectoria, pero la idea es más amplia: los productos de misión crítica no comienzan con una feature. Comienzan con una fricción que alguien decidió no aceptar como inevitable y, muchas veces, es precisamente de ahí de donde nace la mejor investigación.