74% a menos de tempo de desenvolvimento. Cinco vezes mais rápido para entregar uma nova versão de software. Sustentando 33 mil transações via Pix por segundo, para 88 milhões de clientes.
Esse foi o resultado de um projeto de modernização bancária do Banco do Brasil sobre 43 mil caixas eletrônicos, sem trocar um único equipamento físico.
Um problema que qualquer time de tecnologia reconhece
O ponto de partida não era exatamente novo: múltiplos sistemas operacionais rodando sobre um parque de 43 mil equipamentos, acumulados ao longo de mais de uma década (a adoção começou em 2013, com padronização a partir de 2017). Cada camada de software diferente virava mais uma dependência para gerenciar, mais um teste de compatibilidade, mais um motivo para uma atualização simples levar semanas em vez de dias.
Um gestor do banco resumiu o problema com um termo que qualquer desenvolvedor reconhece de cara: “dependency hell”. O inferno das dependências: quando cada peça do sistema depende de versões específicas de outras peças, e mexer em uma arrisca quebrar as demais.
A decisão que não foi trocar o hardware
Diante de um parque de 43 mil máquinas com ciclo de vida de 10 a 13 anos, a resposta mais óbvia pareceria ser substituição física: trocar os equipamentos mais antigos, um a um, por modelos novos. É também a resposta mais cara, mais lenta e mais arriscada operacionalmente, considerando a escala envolvida.
O banco escolheu outro caminho para sua modernização bancária: consolidar toda a rede de autoatendimento em uma única plataforma de software, baseada em código aberto (SUSE Linux Enterprise), substituindo os múltiplos sistemas operacionais que coexistiam até então. O hardware, em grande parte, continuou o mesmo. O que mudou foi a camada que conecta e sustenta esse hardware.
O que esse resultado ensina sobre modernização bancária
O ganho não veio de trocar peça física por peça física. Veio de resolver, na camada de software, o problema que realmente travava a velocidade de entrega: múltiplas versões, múltiplas dependências, múltiplos pontos de falha para cada atualização.
Essa é uma lição que vale além de caixas eletrônicos. Toda infraestrutura crítica acumulada ao longo de anos (em qualquer setor, não só no bancário) tende a herdar esse mesmo tipo de fragmentação: cada geração de equipamento ou sistema trazendo sua própria camada de software, sem que ninguém, em algum momento, pare para unificar a base que sustenta tudo. É nessa unificação, com frequência, que está o ganho real de velocidade, e não na troca física do que já funciona.
Por que isso importa para além do caso específico
Um resultado como esse não se repete automaticamente ao copiar a mesma tecnologia. O que se repete é a lógica por trás da decisão: antes de assumir que modernizar significa substituir fisicamente o que existe, vale perguntar onde, exatamente, está o gargalo: na camada física, na camada de software, ou na forma como as duas se conectam.
Para uma instituição financeira de porte menor que o Banco do Brasil, a escala é outra, mas a pergunta é a mesma: o problema que trava a velocidade de entrega está no equipamento, ou na base de software fragmentada que sustenta ele?
Perguntas frequentes sobre a modernização bancária do Banco do Brasil
1 – O Banco do Brasil trocou os caixas eletrônicos ou só o software?
Na prática, o parque físico continuou, em grande parte, o mesmo. O banco substituiu os múltiplos sistemas operacionais que rodavam sobre os 43 mil equipamentos por uma única plataforma de software, baseada em código aberto (SUSE Linux Enterprise). A modernização bancária aconteceu na camada que sustenta o hardware, não no hardware em si.
2 – O que é “dependency hell” e por que ele trava o desenvolvimento de software?
É o termo usado para descrever uma situação em que cada peça de um sistema depende de versões específicas de outras peças. Quanto mais sistemas operacionais diferentes coexistem em um mesmo parque, mais dependências cruzadas existem e mexer em uma parte aumenta o risco de quebrar outra, o que torna até atualizações simples mais lentas e arriscadas.
3 – É possível modernizar infraestrutura crítica sem trocar todo o parque físico?
O case do Banco do Brasil sugere que sim, ao menos em parte. Consolidar a camada de software que sustenta um parque de equipamentos já existente foi suficiente para reduzir o tempo de desenvolvimento em 74% e acelerar em 5 vezes a entrega de novas versões, sem substituir fisicamente os 43 mil caixas eletrônicos envolvidos.
Fale com a Tinnova sobre como identificar onde está o gargalo real de modernização da sua infraestrutura.
Fonte:
SUSE — case study oficial
Let’s Money
Ti Inside
—
