The market has consolidated a somewhat romanticized view of innovation in technology: a team driven by a great idea, searching for where to apply it. In mission-critical operations, the logic works the other way around. The problem comes first; engineering comes as the response.
In 1992, the company was founded around a very concrete technical challenge: migrating systems from a Honeywell Bull computer to an IBM Mainframe 4341, which at the time was running MVS, the predecessor of z/OS.
The founders, José Ronaldo Martins and Maurício da Costa e Silva, built the company around a principle that would remain present in the decades that followed: researching and developing technology for problems that existing tools were not solving.
The company’s first major product followed the same path. SHAREVSAM was created to address a specific data-sharing problem between online processing in CICS and batch processing. Other R&D initiatives followed, including quality control solutions for COBOL and Db2 SQL.
There is something important in this history: it shows that innovation goes beyond software features. Its starting point lies in the real challenges of operations.
Users see problems that labs cannot reproduce
People who work with critical systems every day know the kinds of exceptions that rarely appear in an architecture designed on paper.
A process may look technically simple until it encounters hundreds of dependencies. A small change may compete for resources with another project. A test may be ready to run but still have to wait for an available environment. A conceptually elegant solution can become impractical once availability, transaction volumes, security, and decades of integration are taken into account.
It was exactly this kind of problem that shaped the space where Eccox Application for Parallel Testing (APT) operates today.
In mainframe environments, one traditional response to conflicts between projects was to replicate environments or serialize testing.
The problem is that replicating structures means maintaining versions, synchronizing databases, managing infrastructure, and consuming specialized labor. The result is a scenario in which different tests compete for data and environments, while teams remain dedicated to preparing and maintaining those structures.
So the engineering question was not simply, “How do we create another test environment?” It was something else: Do we really need to reproduce the entire environment in order to isolate what changed?
APT works from that inversion. Instead of indiscriminately replicating the entire infrastructure, it allows teams to create isolated test tracks using only the components required for a given scenario, while projects continue using the real mainframe structure.
The solution was designed to enable parallel testing without different executions interfering with one another.
This type of answer rarely comes from the abstract observation of a technology trend alone. It comes from living with a problem long enough to realize that the traditional way of solving it does not have to be the only way.
And this logic is not exclusive to smaller companies or specialized products.
When IBM announced the IBM z17 in April 2025, the company said the system was the result of five years of design and development.
During that period, more than 300 patent applications were filed, but there is another number that is just as revealing: the z17 was developed with direct input from more than 100 clients, working in collaboration with IBM Research and Software teams.
It is a revealing combination: hundreds of inventions, but also hundreds of conversations about what actually needed to be solved.
Even a platform with the technological scale of IBM Z does not evolve only from the ability of laboratories to imagine the future. It evolves through direct contact with organizations that need to put AI into production, protect data, process growing volumes, and keep critical systems available.
Technological development still requires deep research. What changes is where the questions come from.
Rather than replacing research, problem-driven R&D gives it direction by focusing it on real challenges.
In mission-critical environments, innovation also means understanding context
This principle is especially relevant in the mainframe world because there is rarely a blank slate.
Organizations are modernizing systems that are already running, processing real business, and carrying rules built over decades. That is why a solution can be technically sophisticated and still fail if adopting it requires the organization to abandon everything that already works.
In the case of testing, APT works with the existing infrastructure. The components required for a specific condition can be cloned and routed to the corresponding test track, while the remaining components continue to be used in the original environment.
It is a different approach. Instead of starting by asking how to move the problem into a new architecture, the first question becomes: What exactly is preventing the user from working better within the architecture they already have?
This kind of question explains much of Eccox’s trajectory. The company was born from a migration project, created its first product to solve an operational processing problem, and continued to place R&D at the center of its business.
More than three decades later, the technologies are different and so are the problems, but the method is still recognizable.
Listening to the market is not simply asking what it wants
There is a difference between user-driven development and custom-built development.
Users do not always know which product they need. What they do know very well is the difficulty they face: where time is lost, where conflicts emerge, where operations depend on manual work, and where change introduces risk.
It is engineering’s role to turn that pain into a solution that can be repeated, automated, and used by other organizations.
Many software categories emerged this way. First, there is a problem that appears to be specific to one situation. Then it becomes clear that other companies are facing the same limitation. When a solution stops solving only one case and begins to encapsulate knowledge that can address an entire class of problems, the project starts becoming a product.
That is the less visible side of R&D in enterprise technology.
The patent, the algorithm, or the architecture appears at the end. Before any of that, there is usually someone saying: “This is not working.”
For Eccox, that kind of listening has always been part of the engineering process, and it remains especially relevant at a time when the mainframe needs to coexist with cloud, AI, new development practices, and ever-greater expectations for speed without compromising the reliability that supports critical operations.
Innovation in this market is not about chasing every new technology that appears. It is about understanding which problems truly deserve a new solution.
APT is one example of that journey, but the idea goes further: mission-critical products do not begin with a feature. They begin with a point of friction that someone decided not to accept as inevitable — and, often, that is where the best research begins.