Resumo Executivo

Andressa Alves Borges; Jamile Raquel Regazzo

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

A modernização de sistemas bancários constitui-se em um desafio estratégico diante das crescentes demandas por desempenho, escalabilidade e eficiência operacional no cenário financeiro contemporâneo. Muitos sistemas legados permanecem sustentados por arquiteturas monolíticas e tecnologias ultrapassadas, o que dificulta a integração com ferramentas modernas e compromete a experiência do usuário final. A transformação digital tem impulsionado organizações a reavaliar infraestruturas de tecnologia da informação, migrando de ambientes tradicionais conhecidos como on-premise para soluções baseadas em computação em nuvem. Essa transição busca atender à necessidade de elasticidade e alta disponibilidade, características fundamentais em mercados competitivos (Marinescu, 2013). Contudo, a migração de sistemas legados impõe desafios técnicos significativos, pois tais estruturas, muitas vezes desenvolvidas com tecnologias obsoletas, não foram concebidas para operar em ambientes distribuídos. Para viabilizar essa transição, torna-se necessário aplicar processos de refatoração, que envolvem a reestruturação interna do código-fonte sem alterar a funcionalidade externa, visando torná-lo modular e compatível com arquiteturas modernas (Fowler, 2018).

A refatoração é fundamental para garantir que os sistemas legados aproveitem recursos da nuvem, como a resiliência. William Opdyke (1992) destaca que a refatoração de frameworks orientados a objetos é uma estratégia eficaz para melhorar a manutenibilidade e a adaptabilidade, facilitando a migração para ambientes modernos. Além dos aspectos técnicos, a adoção da nuvem exige mudanças organizacionais, como a implementação de práticas de DevOps e a reestruturação de equipes. Balalaie et al. (2015) afirmam que a transformação para ambientes cloud-native requer mudanças culturais e a introdução de integração contínua e implantação contínua, além da adoção de microsserviços e containers. A segurança e a conformidade também representam preocupações centrais, exigindo medidas rigorosas em alinhamento com a Lei Geral de Proteção de Dados no Brasil. Marinescu (2013) ressalta que a segurança na nuvem é uma responsabilidade compartilhada entre o provedor e o cliente, tornando imprescindível o estabelecimento de políticas claras de governança e monitoramento contínuo.

O sucesso da migração depende de uma análise criteriosa da criticidade e complexidade dos sistemas existentes. Fowler (2018) defende que a identificação de problemas no código e a priorização de módulos críticos são etapas fundamentais para mitigar riscos. A ausência dessa análise pode levar a interrupções de serviço e altos custos com manutenção corretiva. Outro desafio recorrente é a dependência de fornecedores de nuvem, conhecida como vendor lock-in. Ao utilizar serviços específicos de um único provedor, a empresa pode enfrentar dificuldades futuras para negociações ou novas migrações. Conforme Balalaie et al. (2015), mitigar esse risco exige a adoção de soluções portáveis e arquiteturas desacopladas que facilitem a interoperabilidade entre plataformas. Diante desse panorama, observa-se um déficit de modelos consolidados que orientem de forma prática o processo de refatoração e migração de sistemas legados bancários, justificando a necessidade de estratégias estruturadas que minimizem riscos operacionais e maximizem benefícios estratégicos.

Para a consecução dos objetivos, realizou-se um estudo de caso de natureza aplicada, com delineamento descritivo e abordagem qualitativa. Conforme Yin (2015), o estudo de caso permite explorar fenômenos contemporâneos em seu contexto real, sendo adequado para compreender os desafios e resultados envolvidos na refatoração de uma funcionalidade bancária. A escolha pelo delineamento descritivo justifica-se pela necessidade de detalhar as etapas da migração, documentando as práticas adotadas e os recursos tecnológicos utilizados. De acordo com Gil (2019), a pesquisa descritiva visa a caracterização de fenômenos, sendo utilizada para a formulação de diagnósticos tecnológicos. A abordagem qualitativa permitiu uma compreensão aprofundada da percepção dos profissionais envolvidos, possibilitando a análise de relatos e experiências (Creswell e Poth, 2018). A organização objeto do estudo é uma instituição financeira privada de grande porte, fundada na década de 1940, com atuação nacional e presença internacional, consolidada como uma das maiores do setor bancário no Brasil.

O projeto tratou da migração de uma jornada do sistema legado acessada por meio de uma interface integrada ao aplicativo móvel da instituição. Essa funcionalidade, denominada Menu Cartões, centraliza serviços como visualização de faturas, limites disponíveis, emissão de cartão virtual e pagamento de faturas. Embora parte das jornadas já estivesse em modelo de microsserviços, a página principal e a jornada de fatura permaneciam no sistema monolítico, gerando problemas de desempenho e incompatibilidade com o padrão de design atual da instituição. O sistema legado operava em ambiente on-premise, desenvolvido em Java 7 com tecnologia JSP, versionado pelo software StarTeam e implantado em servidores WebSphere hospedados em datacenter próprio. O banco de dados utilizado era Oracle, e o monitoramento ocorria via Splunk. A arquitetura original era fortemente acoplada, com camada de segurança restrita ao ambiente interno e limitações severas de escalabilidade.

A coleta de dados ocorreu em três abordagens complementares. A primeira consistiu na aplicação de um formulário estruturado pré-implementação em janeiro de 2025, visando identificar desafios no ambiente legado e expectativas da equipe. O instrumento foi respondido por 15 profissionais, incluindo desenvolvedores de níveis júnior a especialistas e líderes técnicos. O projeto de implantação foi realizado entre janeiro e agosto de 2025, abrangendo diagnóstico técnico, planejamento da arquitetura em nuvem, desenvolvimento, testes e rollout. A execução seguiu a metodologia Scrum, com ciclos quinzenais iniciados por reuniões de planejamento e encerrados com retrospectivas. Reuniões diárias garantiam o alinhamento do progresso. Ao término, aplicou-se um segundo formulário em agosto de 2025 para avaliar a percepção sobre o novo ambiente. Além dos formulários, houve observação direta, permitindo acompanhar em tempo real as decisões técnicas e interações da equipe. Métricas operacionais como tempo de resposta, latência e tempo de manutenção foram extraídas de ambos os ambientes para comparação.

A proposta técnica incluiu a substituição das ferramentas legadas por soluções modernas, como GitHub para controle de versões, Spring Boot com Java 19 no backend, Angular 18 no frontend e hospedagem em ambiente Azure. A arquitetura definida após a migração foi composta por três camadas: aplicação, deployment e analytics. No backend, o uso de Spring Boot foi complementado por Cache Redis e Azure Cosmos DB para maior desempenho. O deployment foi automatizado por pipelines no GitHub, com o frontend distribuído via Blob Storage e Content Delivery Network, enquanto o backend passou a ser executado em ambiente Red Hat, orquestrado pelo Azure Kubernetes Service. A camada de observabilidade foi estruturada com Google Analytics para o frontend e Azure Monitor com Log Analytics para o backend, garantindo monitoramento contínuo e segurança entre os fluxos de dados.

Os resultados do diagnóstico inicial revelaram que 100% dos respondentes enfrentavam dificuldades na integração com ferramentas modernas, evidenciando a defasagem tecnológica do ambiente on-premise. Além disso, 93,3% mencionaram interfaces desatualizadas e recursos obsoletos, enquanto 53,3% relataram processos manuais e burocráticos que comprometiam a agilidade. A percepção sobre a eficiência do ambiente antigo foi majoritariamente negativa: 46,7% afirmaram que o sistema não atendia às necessidades, apresentando gargalos e retrabalho, e 40% apontaram funcionalidade parcial com limitações relevantes. Apenas 13,3% consideraram o ambiente satisfatório. No quesito integração, 73,3% dos participantes enfrentavam problemas com ferramentas de integração contínua e versionamento, reforçando a inadequação da arquitetura monolítica frente às práticas de desenvolvimento ágil.

Quanto ao desempenho das aplicações no sistema legado, 73,3% avaliaram como mediano, com falhas pontuais, e 20% como ruim, citando lentidão e instabilidade em horários de pico. As expectativas para a migração eram elevadas: 100% esperavam a adoção de práticas de DevOps e automação, e 93,3% almejavam maior facilidade de integração. A prontidão técnica da equipe era favorável, com 46,7% dos profissionais já possuindo experiência com GitHub, Azure e Spring Boot, enquanto 33,3% tinham experiência parcial. Sobre a curva de aprendizado das tecnologias legadas, como StarTeam e WebSphere, 66,7% a consideraram média e 13,3% alta, devido à falta de documentação e interfaces pouco intuitivas. Os benefícios antecipados com a modernização incluíam melhoria na colaboração (100%), agilidade no desenvolvimento (80%) e integração facilitada (73,3%).

Durante a fase de execução, entre fevereiro e maio, a equipe focou na refatoração de 13 endpoints e na conversão de lógicas obsoletas. A migração para Angular 18 resultou em uma interface responsiva e compatível com o sistema de design da instituição. Cada módulo foi submetido a testes unitários e de integração com JUnit e Jest, garantindo cobertura mínima de 90% exigida pela esteira automatizada. Em maio, preparou-se o ambiente de produção com a criação de clusters no Kubernetes e configuração de ambientes segregados para desenvolvimento, staging e produção. Testes de carga simularam picos de acesso, com análise de registros via Azure Monitor e medições de latência. O rollout progressivo ocorreu entre a última semana de julho e a primeira de agosto de 2025, iniciando em agências de teste controladas antes da expansão total, o que permitiu correções pontuais e mitigação de riscos.

A comparação dos indicadores técnicos evidenciou ganhos expressivos. O tempo médio de resposta das aplicações caiu de 620 ms no ambiente on-premise para 280 ms na nuvem, uma redução de aproximadamente 55%. A latência entre componentes, que era de 185 ms, foi reduzida para 74 ms, representando um ganho superior a 60%. Esse resultado está diretamente ligado ao uso de containers e clusters Kubernetes, que permitem maior proximidade lógica entre serviços. O tempo médio de manutenção corretiva apresentou a queda mais drástica, de 12 horas para apenas três horas, graças à automação dos pipelines de deploy que facilitam a detecção de falhas e a realização de rollbacks rápidos. A curva de aprendizado médio para adaptação das equipes também melhorou, reduzindo-se de três semanas para uma semana, fruto da padronização de ferramentas e treinamentos direcionados.

No quesito escalabilidade, o modelo anterior era restrito pela infraestrutura física, exigindo aquisição de hardware. Na nuvem, a escalabilidade tornou-se automática e elástica, ajustando-se à demanda em tempo real. A avaliação pós-implantação confirmou a percepção de melhoria: 60% dos respondentes notaram ganhos significativos de desempenho e 33,3% perceberam melhorias em aspectos específicos. Sobre a experiência com o novo ecossistema, 33,3% a classificaram como muito positiva e 20% como boa, embora 40% tenham considerado regular devido à curva de aprendizado inicial. A agilidade nos processos de manutenção e desenvolvimento foi reconhecida por 80% da equipe, validando a eficácia da automação e das ferramentas de monitoramento.

Entretanto, a percepção sobre custos operacionais foi divergente. Apenas 6,7% notaram redução clara, enquanto 53,3% não souberam avaliar, indicando que a governança financeira da nuvem não foi amplamente comunicada aos times técnicos. Sobre a adaptação às novas ferramentas, 26,7% consideraram o processo fluido e 53,3% positivo com dificuldades pontuais. A nova arquitetura facilitou a escalabilidade e segurança para 66,7% dos participantes. Ao final, 60% recomendariam a migração com certeza e 33,3% recomendariam com ressalvas sobre a necessidade de preparação. Os principais desafios enfrentados foram a curva de aprendizado elevada (73,3%) e problemas na integração com sistemas legados remanescentes (60%). Outros obstáculos incluíram resistência a mudanças (26,7%) e atrasos no cronograma (20%).

A análise dos dados demonstra que os desafios estiveram concentrados em fatores humanos e organizacionais, além da complexidade técnica de integração. A percepção negativa sobre a eficiência do sistema antigo, compartilhada por 87% dos participantes antes da migração, justifica a urgência da modernização. Os achados são consistentes com a literatura de engenharia de software, que associa legados monolíticos à dívida técnica (Seacord, 2003). A melhoria na confiabilidade e no retrabalho corrobora as teses de Pressman e Maxim (2021). A adoção de microsserviços refatorados e pipelines de integração contínua proporcionou a agilidade esperada, conforme preconizado por Humble e Farley (2010). Os indicadores técnicos confirmam que decisões arquiteturais fundamentadas produzem impactos mensuráveis em atributos de qualidade (Bass, Clements e Kazman, 2021).

A percepção da equipe validou os ganhos objetivos, com 80% destacando a agilidade operacional. Forsgren et al. (2018) já haviam demonstrado que equipes que aplicam DevOps relatam maior produtividade. A melhoria em escalabilidade e segurança, percebida por dois terços dos respondentes, decorre da orquestração eficiente e do monitoramento contínuo (Burns et al., 2022). O distanciamento da equipe técnica em relação aos custos sugere uma centralização da governança financeira em níveis de gestão. Os desafios de integração com o legado confirmam a utilidade de padrões como o Strangler Fig para transições graduais (Fowler, 2004). A resistência observada reforça a natureza sociotécnica de projetos de transformação digital (Fitzgerald e Stol, 2017). Em síntese, a modernização potencializou a eficiência, mas exigiu atenção equilibrada aos aspectos técnicos e humanos.

Conclui-se que o objetivo foi atingido, uma vez que a estratégia de migração proposta resultou em melhorias mensuráveis de 55% no tempo de resposta e 60% na latência, além de reduzir o tempo de manutenção de 12 para três horas. A transição do ambiente on-premise para a nuvem Azure, utilizando Spring Boot e Kubernetes, conferiu ao sistema bancário a escalabilidade e a agilidade necessárias para o atendimento das demandas digitais. Apesar de desafios como a curva de aprendizado elevada e a complexidade de integração com módulos remanescentes, a aceitação da nova arquitetura foi alta, com recomendação de 93,3% da equipe técnica. As limitações do estudo envolveram o acesso restrito a dados financeiros detalhados e o recorte em uma única jornada funcional, recomendando-se que pesquisas futuras ampliem o escopo para outras áreas críticas e aprofundem a análise de governança de custos em ambientes de grande escala.

Referências Bibliográficas:

Balalaie, A.; Heydarnoori, A.; Jamshidi, P. 2015. Migrating to Cloud-Native Architectures Using Microservices: An Experience Report. arXiv preprint arXiv:1507.08217.

Bass, L.; Clements, P.; Kazman, R. 2021. Software architecture in practice. 4. ed. Addison-Wesley, Boston, MA, EUA.

Burns, B.; Beda, J.; Hightower, K. 2022. Kubernetes: up & running. 3. ed. O’Reilly Media, Sebastopol, CA, EUA.

Creswell, J. W.; Poth, C. N. 2018. Qualitative Inquiry and Research Design: Choosing Among Five Approaches. 4. ed. SAGE Publications, Thousand Oaks, CA, EUA.

Fitzgerald, B.; Stol, K. J. 2017. Continuous software engineering: a roadmap and agenda. Journal of Systems and Software, 123(1): 176-189.

Forsgren, N.; Humble, J.; Kim, G. 2018. Accelerate: the science of lean software and DevOps. 1. ed. IT Revolution Press, Portland, OR, EUA.

Fowler, M. 2004. Strangler fig application. Disponível em: <https://martinfowler.com/bliki/StranglerFigApplication.html>. Acesso em: 30 ago. 2025.

Fowler, M. 2018. Refactoring: Improving the Design of Existing Code. 2. ed. Addison-Wesley Professional, Boston, MA, EUA.

Gil, A. C. 2019. Métodos e Técnicas de Pesquisa Social. 7. ed. Atlas, São Paulo, SP, Brasil.

Humble, J.; Farley, D. 2010. Continuous delivery: reliable software releases through build, test, and deployment automation. 1. ed. Addison-Wesley, Boston, MA, EUA.

Marinescu, D. C. 2013. Cloud Computing: Theory and Practice. Elsevier Science, Burlington, MA, EUA.

Opdyke, W. F. 1992. Refactoring Object-Oriented Frameworks. Tese de Doutorado em Ciência da Computação. University of Illinois at Urbana-Champaign, Urbana, IL, EUA.

Pressman, R. S.; Maxim, B. R. 2021. Software engineering: a practitioner’s approach. 9. ed. McGraw-Hill Education, Nova Iorque, NY, EUA.

Seacord, R. C. 2003. Modernizing legacy systems: software technologies, engineering processes, and business practices. 1. ed. Addison-Wesley, Boston, MA, EUA.

Yin, R. K. 2015. Estudo de Caso: Planejamento e Métodos. 5. ed. Bookman, Porto Alegre, RS, Brasil.

Resumo executivo oriundo de Trabalho de Conclusão de Curso de Especialização em Gestão de Projetos do MBA USP/Esalq

_{Saiba mais sobre o curso; clique aqui:}