Modernização Legacy em banco tier 1

Contexto

Uma instituição financeira tier-1 europeia executa os seus processos de computação financeira crítica (risco, tesouraria, valorização) sobre um core Oracle com lógica em PL/SQL, um grid IBM Spectrum Symphony e sistemas de mercado como Murex e Algorithmics. É uma operação 24/7: não existe uma janela em que o sistema possa parar.

O core tinha crescido durante anos sob a forma de monólitos PL/SQL difíceis de evoluir, com deploys manuais e processos cujo tempo de execução já não cabia nas janelas de negócio. O objetivo foi reduzir esses tempos e modernizar a forma de entregar software sem tocar na disponibilidade.

O desafio

Três restrições marcaram o projeto:

• Processos de computação financeira crítica com tempos insustentáveis, que bloqueavam operações do negócio.
• Monólitos Oracle com PL/SQL crítico acoplado, sem possibilidade de alterar uma peça sem arriscar o conjunto.
• Operação 24/7 e integrações com Murex e Algorithmics que tinham de manter-se intactas durante toda a transição.

Abordagem por fases

A modernização foi executada como uma sucessão de fases controladas, cada uma com validação e capacidade de reversão.

1. 01

   Diagnóstico do código e do grid

   Identificação do PL/SQL que concentrava o tempo de computação e da utilização real dos recursos do grid.

2. 02

   Refatorização e desacoplamento

   Reescrita do PL/SQL crítico e separação progressiva dos monólitos Oracle em componentes implementáveis de forma independente.

3. 03

   Pipeline DevOps e GitOps

   Automatização dos deploys: cada alteração versionada, testada e promovida de forma reproduzível.

4. 04

   Migração por fases sem downtime

   Entrada em produção componente a componente, mantendo as integrações com Murex e Algorithmics e a operação 24/7.

Arquitetura e estratégia

O princípio foi o mesmo que aplicamos nos restantes projetos de banca tier-1: estender e desacoplar em vez de substituir. O grid Symphony e o core Oracle continuam no seu lugar; o que muda é como se distribui o trabalho (utilização do grid) e como se entrega o software (pipeline automatizado em vez de deploys manuais).

Resultados mensuráveis

Resultados validados em produção:

Números agregados e anonimizados por acordo de confidencialidade. Fonte: projetos da Vermont Solutions.

Lições aplicáveis

• Num core 24/7 a migração por fases com capacidade de reversão não é opcional: é a única forma de avançar sem expor o negócio.
• Automatizar a entrega (DevOps + GitOps) reduz erros e torna cada deploy previsível e auditável.
• Medir a utilização real do grid antes de o ampliar evita investimentos desnecessários: a margem estava na distribuição, não no hardware.

Enquadramento regulatório

A computação de risco na banca tier-1 é matéria supervisionada; a modernização foi desenhada para reforçar a evidência de controlo.

• Basileia III/IV: cálculos de capital e de risco dentro das janelas exigidas.
• DORA (art. 28.º): rastreabilidade das alterações, resiliência operacional e gestão de prestadores terceiros TIC.
• BCBS 239: agregação de dados de risco com processos documentados e reproduzíveis.

Perguntas frequentes

Conteúdo relacionado

• Serviço: modernização de sistemas legacy →
• Serviço: HPC e Grid Computing →
• Produto: add-on para IBM Spectrum Symphony →
• Caso: extensão dinâmica do GRID à nuvem na banca →