Num artigo anterior, explorei como o mainframe offload pode ajudar as organizações a desbloquear dados de sistemas legacy e a reduzir a carga operacional da infraestrutura core. Ao replicar dados para plataformas modernas através de mecanismos de CDC, as organizações ganham flexibilidade, reduzem custos de infraestrutura e passam a conseguir expor informação que antes estava presa em sistemas fortemente acoplados.
Mas extrair os dados é apenas metade da jornada. A pergunta que se segue – e aquela que, em última análise, determina o valor de negócio de todo este esforço – é: o que acontece a esses dados depois de serem libertados?
A verdadeira transformação começa quando os dados deixam de ser movidos periodicamente e passam a fluir continuamente, chegando aos sistemas certos e às pessoas certas no momento em que são relevantes. É aqui que a arquitetura event-driven se torna o próximo passo natural na jornada de mainframe offload.
Os limites de pensar em batch
Durante décadas, a abordagem dominante ao processamento de dados foi orientada a batch. Os dados são extraídos dos sistemas operacionais em intervalos definidos, processados e carregados em camadas analíticas ou de reporting. Este modelo serviu bem as organizações quando os volumes de dados eram mais geríveis e a capacidade de resposta em tempo real não era um fator diferenciador.
O desafio é que a maioria dos processos de negócio não é, por natureza, orientada a batch. Um cliente que faz um pagamento não espera por um processo noturno para confirmar se a transação foi aprovada. Uma tentativa de fraude não se agenda para horas de menor tráfego. Uma rutura de stock numa rede de retalho não fica em pausa até o relatório da manhã ser gerado.
Na prática, as organizações que dependem de arquiteturas batch encontram frequentemente limitações como:
- Deteção tardia de anomalias e problemas operacionais, aumentando o seu impacto no negócio;
- Processos orientados ao cliente que não têm a capacidade de resposta esperada nas experiências digitais;
- Camadas analíticas e de reporting que refletem o estado do negócio de há várias horas, não o estado atual;
- Equipas operacionais a trabalhar com dashboards que estão sempre a tentar acompanhar a realidade, em vez de a antecipar;
- Complexidade de integração crescente, à medida que mais sistemas precisam de aceder aos mesmos dados em diferentes intervalos.
Estas limitações não resultam da falta de dados. Resultam de uma arquitetura que trata os dados como algo que deve ser movido periodicamente, em vez de algo que flui continuamente.
Uma forma diferente de pensar o movimento dos dados
As arquiteturas event-driven assentam numa premissa fundamentalmente diferente. Em vez de mover dados em massa em intervalos programados, tratam cada alteração de estado como um evento – algo que aconteceu e a que outros sistemas podem observar e reagir de imediato.
Uma forma simples de pensar sobre isto é comparar a receção de um jornal impresso com um feed de notícias em direto. Ambos entregam informação, mas apenas um a entrega no momento certo, quando é relevante. As arquiteturas event-driven aplicam a mesma lógica aos dados de negócio: em vez de esperar pela próxima extração programada, os sistemas são notificados no momento em que algo relevante acontece.
Este modelo tem uma implicação importante para organizações que já investiram em mainframe offload. Os dados replicados através de CDC – registos transacionais, atualizações de contas, eventos operacionais – tornam-se muito mais valiosos quando são distribuídos em tempo real, em vez de ficarem apenas disponíveis num repositório estático. A camada de offload fornece a base; a camada de streaming é o que a ativa.
Onde os dados em tempo real criam valor de negócio tangível
O valor das arquiteturas event-driven torna-se mais evidente quando analisado através de resultados de negócio concretos.
Nos serviços financeiros, a capacidade de processar eventos transacionais quase em tempo real permite um conjunto de capacidades que simplesmente não são possíveis num modelo batch. Os clientes podem receber notificações imediatas após cada transação com cartão, com informação contextual que aumenta a sua sensação de controlo e segurança.
Os modelos de deteção de fraude podem avaliar padrões à medida que surgem, em vez de o fazerem apenas depois do evento, reduzindo drasticamente a janela de exposição. Alertas personalizados com base em limites de gastos ou padrões de utilização podem ser acionados no momento em que se tornam relevantes, e não apenas na manhã seguinte.
No retalho, as arquiteturas de streaming suportam use cases como a visibilidade de inventário em tempo real em redes de lojas, permitindo uma disponibilidade de dados mais precisa para os clientes e uma resposta operacional mais rápida a variações de stock. A monitorização da atividade dos clientes em canais digitais e físicos torna-se possível sem introduzir carga adicional nos sistemas operacionais core.
O que estes exemplos têm em comum é um padrão claro: quanto mais próxima a organização estiver de agir sobre os dados no momento em que são gerados, maior será o impacto no negócio.
Transformar a arquitetura de streaming numa capacidade escalável
Um dos desafios práticos na adoção de arquiteturas event-driven é o esforço de engenharia necessário para as construir e manter de forma consistente. Cada novo use case de streaming traz o risco de se tornar uma implementação feita à medida.
Uma abordagem mais sustentável passa por construir uma camada reutilizável que normalize a forma como os use cases de streaming são definidos, implementados e operados. Em vez de reconstruir a mesma lógica de processamento para cada novo requisito, as equipas trabalham com um conjunto partilhado de componentes que tratam dos padrões comuns – ingestão de dados, transformação, enriquecimento, encaminhamento para múltiplos destinos – mantendo flexibilidade suficiente para acomodar diferentes níveis de complexidade.
A implicação desta abordagem para o negócio é significativa. Quando o trabalho fundacional é feito uma vez e aplicado repetidamente, o time-to-market de novos use cases diminui substancialmente.
Na Xpand IT, é assim que abordamos o streaming à escala: partindo de uma base arquitetural sólida construída sobre a camada de offload e acelerando depois a entrega de use cases sobre essa fundação. O objetivo não é apenas fazer com que um use case funcione bem em tempo real, mas transformar o tempo real numa capacidade que a organização consegue aplicar de forma transversal.
Conclusão: completar a jornada do offload ao impacto
O mainframe offload cria as condições para a transformação, mas são as arquiteturas event-driven que a concretizam. Em conjunto, formam um caminho coerente da dependência legacy para a capacidade em tempo real – um caminho em que os sistemas core continuam a fazer aquilo que fazem melhor, enquanto os dados fluem livremente para onde criam mais valor.
As organizações que já deram o primeiro passo de retirar dados da infraestrutura legacy estão bem posicionadas para dar o próximo. A base já existe. O que falta é ativá-la e construir a camada de streaming que transforma dados libertados em decisões que acontecem à velocidade do negócio.