O mercado consolidou uma visão romantizada sobre inovação em tecnologia: uma equipe guiada por uma grande ideia em busca de aplicação. Nas operações de missão crítica, a lógica se inverte. O problema surge primeiro; a engenharia vem como resposta.

A história da Eccox começou assim.

Em 1992, a empresa nasceu a partir de um desafio técnico concreto: migrar sistemas de um computador Honeywell Bull para um IBM Mainframe 4341, então operando com MVS, predecessor do z/OS.

Os fundadores José Ronaldo Martins e Maurício da Costa e Silva organizaram a empresa em torno de uma lógica que continuaria presente nas décadas seguintes: pesquisar e desenvolver tecnologia para problemas que as ferramentas disponíveis não estavam resolvendo.

O primeiro produto importante também seguiu esse caminho. O SHAREVSAM surgiu para tratar um problema específico de compartilhamento de dados entre processamento online em CICS e processamento batch. Depois vieram outras iniciativas de P&D, inclusive as soluções de controle de qualidade para COBOL e SQL Db2.

Há algo importante nessa história: ela revela que a inovação vai além das funcionalidades de um software: seu ponto de partida está nos desafios reais da operação.

O usuário enxerga problemas que o laboratório não consegue reproduzir

Quem trabalha diariamente com sistemas críticos conhece exceções que dificilmente aparecem em uma arquitetura desenhada no papel.

Um processo pode parecer tecnicamente simples até encontrar centenas de dependências. Uma mudança pequena pode disputar recursos com outro projeto. Um teste pode estar pronto para execução, mas precisar esperar pelo ambiente. Uma solução elegante conceitualmente pode se tornar inviável quando entram na conta disponibilidade, volumes transacionais, segurança e décadas de integração.

Foi exatamente um problema desse tipo que deu forma ao território em que hoje atua o Eccox Application for Parallel Testing (APT).

Em ambientes mainframe, uma resposta tradicional aos conflitos entre projetos era replicar ambientes ou serializar testes. 

O problema é que replicar estruturas implica manter versões, sincronizar bases, administrar infraestrutura e consumir trabalho especializado. O cenário é o de diferentes testes disputando dados e ambientes, com equipes dedicadas à preparação e manutenção dessas estruturas.

A pergunta de engenharia, então, não era simplesmente “como criar mais um ambiente de teste?”. Era outra: é realmente necessário reproduzir todo o ambiente para conseguir isolar aquilo que mudou?

O APT trabalha a partir dessa inversão. Em vez de replicar indiscriminadamente toda a infraestrutura, permite criar pistas de teste isolando os componentes necessários a determinado cenário, enquanto os projetos continuam utilizando a estrutura real do mainframe. 

A solução foi concebida para permitir testes paralelos sem que diferentes execuções interfiram umas nas outras.

Esse tipo de resposta dificilmente surge apenas da observação abstrata de uma tendência tecnológica. Surge quando alguém convive tempo suficiente com um problema para perceber que a maneira tradicional de resolvê-lo não precisa ser a única.

Essa lógica não é exclusividade de empresas menores ou de produtos especializados.

Quando anunciou o IBM z17, em abril de 2025, a IBM informou que o sistema era resultado de cinco anos de design e desenvolvimento. 

Nesse período, foram depositados mais de 300 pedidos de patente, mas há outro número tão interessante quanto esse: o z17 foi desenvolvido com contribuição direta de mais de 100 clientes, em colaboração com os times de IBM Research e Software. 

É uma combinação reveladora: centenas de invenções, mas também centenas de conversas sobre o que precisava ser resolvido.

Mesmo uma plataforma com o porte tecnológico do IBM Z não evolui apenas a partir da capacidade dos laboratórios de imaginar o futuro. Ela evolui em contato com organizações que precisam colocar IA em produção, proteger dados, processar volumes crescentes e manter sistemas críticos disponíveis.

O desenvolvimento tecnológico continua exigindo pesquisa profunda. O que muda é a origem das perguntas.

Em vez de abandonar a pesquisa, o P&D orientado ao problema a direciona para a resolução de desafios reais.

Em missão crítica, inovação também é conhecer o contexto

Esse princípio é especialmente relevante no mainframe porque não costuma existir uma folha em branco.

As empresas estão modernizando sistemas que já operam, processam negócios reais e acumulam regras construídas ao longo de décadas. Por isso, uma solução pode ser tecnicamente sofisticada e ainda assim fracassar se exigir que a organização abandone tudo aquilo que já funciona para adotá-la.

No caso dos testes, o APT parte da infraestrutura existente. Os componentes necessários para determinada condição podem ser clonados e direcionados à pista correspondente; os demais continuam sendo utilizados no ambiente original.

É uma diferença de abordagem. Em vez de começar perguntando como transportar o problema para uma nova arquitetura, começa-se perguntando o que exatamente está impedindo o usuário de trabalhar melhor na arquitetura que ele possui.

Esse tipo de pergunta explica boa parte da trajetória da Eccox. A empresa nasceu de um projeto de migração, criou seu primeiro produto para resolver um problema operacional de processamento e continuou colocando P&D no centro do negócio.

Mais de três décadas depois, as tecnologias são diferentes e os problemas também, mas o método continua reconhecível.

Ouvir o mercado não é simplesmente perguntar o que ele quer

Há uma diferença entre desenvolvimento orientado pelo usuário e desenvolvimento por encomenda.

Nem sempre o usuário sabe qual produto precisa. O que ele conhece profundamente é a dificuldade que enfrenta: onde perde tempo, onde existe conflito, onde a operação depende de trabalho manual, onde uma mudança representa risco.

Cabe à engenharia transformar essa dor em uma solução que possa ser repetida, automatizada e utilizada por outras organizações.

Foi assim que muitas categorias de software surgiram. Primeiro existe um problema aparentemente particular. Depois se percebe que outras empresas enfrentam a mesma limitação. Quando a solução deixa de resolver apenas um caso e passa a encapsular conhecimento para resolver uma classe inteira de problemas, o projeto começa a se tornar produto.

Esse é o aspecto menos visível de P&D em tecnologia empresarial.

A patente, o algoritmo ou a arquitetura aparecem no final. Antes deles, normalmente existe alguém dizendo: “desse jeito não está funcionando”.

Para a Eccox, essa escuta sempre fez parte do processo de engenharia e continua especialmente relevante num momento em que o mainframe precisa conviver com cloud, IA, novas práticas de desenvolvimento e expectativas cada vez maiores de velocidade sem abrir mão da confiabilidade que sustenta operações críticas.

Inovar nesse mercado não é perseguir toda novidade que aparece. É entender quais problemas realmente merecem uma solução nova.

O APT é um exemplo dessa trajetória, mas a ideia é mais ampla: produtos de missão crítica não começam com uma feature. Começam com uma fricção que alguém decidiu não aceitar como inevitável e, muitas vezes, é daí que nasce a melhor pesquisa.