A narrativa predominante sempre tratou a arquitetura híbrida como um estado intermediário. O mainframe permaneceria responsável pelos sistemas críticos enquanto aplicações e dados fossem gradualmente transferidos para cloud, culminando em uma arquitetura mais simples e concentrada em plataformas consideradas modernas.
Os movimentos recentes do mercado colocam essa leitura em dúvida.
O híbrido já é o modelo dominante entre as organizações e, ao mesmo tempo, muitas delas aumentaram o uso do mainframe. As empresas estão obtendo retorno financeiro nas três estratégias analisadas: modernizar no mainframe, integrar o mainframe a outras plataformas e migrar workloads selecionados.
Para muitas empresas, mainframe + cloud pode deixar de ser uma arquitetura provisória e se tornar o desenho mais racional para o negócio.
Em vez de invalidar os projetos de migração, a premissa passa a ser reconhecer que determinadas cargas continuam fazendo sentido no mainframe, enquanto outras pertencem à cloud, a plataformas de dados ou a aplicações distribuídas.
Se esse ambiente híbrido é permanente, porém, surge uma questão mais difícil do que simplesmente conectar tecnologias: como operar processos de negócio que atravessam todas elas?
O problema já não é fazer sistemas conversarem
A primeira geração de iniciativas híbridas concentrou boa parte do esforço em conectividade. Era necessário expor aplicações, abrir APIs, criar integrações e permitir que sistemas em plataformas diferentes trocassem dados.
Esse trabalho continua sendo necessário, mas já não resolve sozinho o problema operacional.
Uma transação iniciada em um aplicativo pode depender de um processamento no mainframe, acionar um serviço em cloud, alimentar uma plataforma de dados e, depois, disparar outro processo em um sistema corporativo.
Cada componente pode funcionar perfeitamente de forma isolada e, ainda assim, o processo completo falhar por uma dependência não executada, uma ordem incorreta, um atraso ou uma transferência de dados interrompida.
Por isso, à medida que a arquitetura se torna híbrida, a unidade operacional deixa de ser apenas o sistema e passa a ser o workflow que atravessa vários sistemas.
Um processo de fechamento financeiro, por exemplo, pode começar em aplicações distribuídas, depender de jobs em z/OS, movimentar arquivos, executar transformações em cloud e terminar em uma plataforma analítica.
Uma rotina de processamento de dados pode combinar aplicações on-premises com serviços da AWS, Azure ou Google Cloud. Em ambos os casos, a disponibilidade de cada plataforma isoladamente diz pouco sobre a capacidade de o processo terminar dentro do SLA.
O desafio passa a ser garantir que essas dependências funcionem como uma única operação.
O híbrido aumenta a flexibilidade e também as dependências
A principal vantagem de uma arquitetura híbrida é não obrigar toda aplicação a caber no mesmo modelo tecnológico. Cada workload pode permanecer ou ser desenvolvido onde suas características de performance, custo, segurança, proximidade dos dados e velocidade de evolução façam mais sentido.
Essa liberdade, porém, cria uma quantidade maior de relações entre plataformas.
O problema aparece quando cada ambiente também mantém sua própria lógica de automação. O mainframe tem um scheduler. A cloud utiliza outro mecanismo. A plataforma de dados possui seu próprio workflow. Uma área de negócio controla outra parte do processo.
Aos poucos, um serviço que parece único para o usuário passa a depender de várias cadeias independentes. A arquitetura está integrada, mas a execução continua fragmentada.
Esse é um dos motivos pelos quais o debate sobre automação está evoluindo para o de orquestração. Automatizar uma atividade significa permitir que ela aconteça sem intervenção manual. Orquestrar significa coordenar diferentes atividades, dependências e plataformas para que o processo completo seja executado na sequência necessária.
A distinção é relevante em ambientes híbridos porque o problema raramente está em um único job. Está no que precisa acontecer antes e depois dele.
É para preencher essa lacuna que a BMC posiciona o Control-M.
A plataforma foi desenvolvida para orquestrar workflows de aplicações e dados em ambientes heterogêneos. No contexto de mainframe, a BMC destaca a possibilidade de conectar jobs nativos da plataforma a processos distribuídos e cloud, administrando essas dependências a partir de uma visão unificada.
O produto também oferece gerenciamento de SLA, automação de recuperação e integração entre z/OS e ambientes como AWS e Azure.
A proposta não é retirar o processamento do mainframe, mas permitir que ele participe do mesmo fluxo operacional que as demais plataformas.
Isso faz diferença porque, em muitas empresas, a modernização digital não substituiu os processos executados no mainframe; ela adicionou novas etapas ao redor deles. Aplicativos móveis, APIs, serviços em cloud, plataformas analíticas e novos canais passaram a consumir ou produzir informações associadas ao core.
O workflow de negócio, portanto, ficou maior do que qualquer uma das plataformas que o executam.
O Control-M atua nessa camada de coordenação. A solução é uma plataforma de orquestração de aplicações e dados capaz de trabalhar em ambientes híbridos e multicloud e integrar diferentes fontes de dados, aplicações e serviços cloud.
Em vez de manter schedulers e mecanismos de controle separados para cada ambiente, a organização pode definir dependências que atravessam essas fronteiras e acompanhar a execução do processo de ponta a ponta.
O SLA pertence ao processo, não à plataforma
Essa mudança também altera a maneira de pensar disponibilidade.
Imagine uma rotina que precisa estar concluída até as 7h para que uma operação de negócio seja iniciada. Parte dela roda no mainframe. Outra etapa processa dados em cloud. Depois, uma aplicação distribuída gera um resultado que alimenta um sistema corporativo.
Para o negócio, não importa se cada plataforma individualmente registrou disponibilidade de 99,99%. O que importa é se o processo terminou até as 7h.
Essa diferença pode parecer óbvia, mas arquiteturas híbridas tornam esse tipo de acompanhamento mais difícil. Quando cada etapa possui ferramentas, equipes e mecanismos próprios de monitoramento, identificar onde o fluxo parou pode exigir a correlação manual de informações espalhadas por diferentes ambientes.
Uma camada de orquestração cria outra perspectiva: o objeto monitorado deixa de ser apenas o job individual e passa a incluir o encadeamento que entrega o serviço.
A BMC destaca justamente recursos de gerenciamento de SLA e visualização end-to-end entre mainframe, aplicações híbridas e ambientes multicloud no Control-M. A plataforma também oferece integrações com mais de uma centena de serviços e tecnologias de cloud, aplicações e dados.
Isso não elimina incidentes, mas reduz a distância entre um atraso técnico e a identificação de seu impacto no processo de negócio.
Há outro aspecto que costuma ser subestimado nessa discussão.
Quando equipes adotam serviços cloud com mais autonomia, o número de tecnologias envolvidas nos workflows aumenta. Data teams podem utilizar Snowflake ou Databricks. Desenvolvedores podem acionar funções serverless. Aplicações corporativas continuam dependendo de SAP. O mainframe permanece no centro de processos críticos.
Sem uma camada comum de coordenação, a automação tende a crescer em silos.
Uma equipe cria scripts. Outra utiliza o scheduler nativo da plataforma. Uma terceira monta pipelines próprios. A soma dessas decisões pode funcionar localmente, mas torna mais difícil responder perguntas simples em escala empresarial:
Quem depende de quem?
Qual processo está atrasado?
Qual SLA está em risco?
Quem pode alterar o workflow?
O que foi executado e em qual ordem?
Por isso, orquestração não é apenas uma questão de conveniência operacional. Ela também cria condições para governança.
O Control-M oferece uma camada central para definição, acompanhamento e controle de workflows, combinando recursos de automação, self-service, políticas de acesso, auditoria e visualização.
A BMC posiciona essa capacidade como uma forma de coordenar ambientes complexos sem perder controle operacional à medida que aplicações e dados se distribuem por diferentes infraestruturas. (BMC Software )
A ideia é especialmente relevante para organizações nas quais a autonomia das equipes precisa coexistir com requisitos elevados de segurança e confiabilidade.
Talvez não exista uma “plataforma de chegada”
A própria evolução das estratégias de modernização sugere que muitas empresas estão abandonando a ideia de um destino tecnológico único.
Em vez de grandes migrações lineares, as empresas estão adotando abordagens mais graduais, combinando modernização na plataforma, integração e migração seletiva. Esse pragmatismo tem uma consequência arquitetural.
Se diferentes workloads encontram destinos diferentes, a arquitetura final tende a continuar heterogênea.
A cloud não desaparece. O mainframe também não. Plataformas de dados, SaaS e aplicações distribuídas continuam sendo adicionadas ao ambiente.
A questão estratégica deixa de ser como chegar a uma plataforma única e passa a ser como operar um negócio que depende permanentemente de várias plataformas.
Nesse cenário, o híbrido não representa necessariamente uma modernização pela metade. Pode ser precisamente o resultado de uma decisão madura sobre onde cada workload deve operar.
O próximo desafio é fazer o híbrido funcionar como um só ambiente
A modernização do mainframe já avançou bastante na discussão sobre APIs, cloud, DevOps e integração. A etapa seguinte exige olhar para o que acontece depois que essas conexões são criadas.
Uma transação pode começar no core e terminar na cloud. Um pipeline de dados pode atravessar plataformas distintas. Uma rotina crítica pode depender simultaneamente de aplicações antigas e serviços criados há poucos meses.
Para o usuário e para o negócio, porém, tudo isso continua sendo um único processo.
É nessa camada que soluções de orquestração como o BMC Control-M, representado pela Eccox, ganham relevância. O produto permite coordenar workflows de aplicações e dados entre mainframe, ambientes distribuídos e cloud, mantendo dependências, visibilidade e gestão de SLA dentro de uma mesma lógica operacional.
Se a arquitetura híbrida deixou de ser uma etapa temporária, a capacidade de operá-la também precisa deixar de ser improvisada.
O desafio já não é apenas conectar mainframe e cloud. É garantir que o processo que depende dos dois continue funcionando como se a fronteira entre eles não existisse.
About Post Author
