Imagine o seu sistema bancário central como uma torre Jenga. Cada ajuste de produto, integração ou mudança de compatibilidade é como retirar outro bloco e torcer para que a pilha não entre em colapso, e quanto mais alto você sobe, mais cada movimento é governado pelo medo e não pela ambição.
Para muitos bancos, atingir o “teto central” é assim: não apenas ficar sem capacidade, mas chegar a um ponto em que o risco de atingir o núcleo começa a limitar o que a organização pode fazer pelos seus clientes.
Historicamente, as instituições financeiras tiveram que escolher entre facilidade de configuração, escalabilidade e flexibilidade. Qualquer que fosse a rota que escolhessem, em algum momento atingiriam o teto central. Um núcleo pronto para 2040 e além deve oferecer tudo, sem concessões.
O teto central é um problema duplo para os bancos.
A primeira vertente do problema ocorre quando as limitações de escalabilidade incorporadas em uma arquitetura – no número de clientes ou transações por segundo – começam a aparecer como problemas evidentes de desempenho. Isso pode ser devido à queda de ingressos em horários de pico, resposta lenta em canais digitais ou incapacidade de continuar adicionando novos volumes sem compromissos dolorosos em outras áreas.
E há ainda outro limite máximo que os bancos tendem a atingir mais cedo: as restrições à mudança. Internamente, você vê isso como um atrito entre código e cliente. Os engenheiros lutam para fazer mudanças, adaptar-se ou agir rapidamente porque cada mudança traz a possibilidade de efeitos colaterais não intencionais em algum lugar no fundo da pilha. Os lançamentos são feitos menos para desbloquear novos valores e mais para não quebrar o que já funciona.
É tentador atribuir a culpa apenas aos mainframes legados, mas muitas plataformas mais recentes estão alcançando um lugar semelhante. Alguns são construídos em torno de configuração pura: rápidos de implementar e familiares às equipes de negócios, mas sua capacidade de diferenciação é, em última análise, limitada pelo que o fornecedor escolheu construir e pelo que ele decidiu incluir em seu roteiro.
Outros oferecem uma verdadeira flexibilidade de enquadramento – dando aos bancos a liberdade de escolher cada aspecto do seu núcleo – mas essa abertura requer recursos de engenharia qualificados e uma governação cuidadosa. Sem ambos, a liberdade de construir torna-se a liberdade de criar o seu próprio neo-legado.
A questão é como encontrar um meio-termo – um que evite tanto a construção personalizada de estilo neo-herdado quanto os modelos somente de configuração rígida. Para mim, a mudança mais importante é a adoção de um princípio aberto-fechado no design central. O princípio aberto-fechado foi cunhado pela primeira vez por Bertrand Meyer em seu livro de 1988, Building Object-Oriented Software. “Entidades de software.” Ele escreveu: “Deveríamos estar abertos à extensão, mas fechados à mudança”. No core banking, isto permitirá que os bancos fechem o core à mudança direta, mas abram a expansão para que o negócio possa inovar com segurança em torno dele.
