Fazendo o banco composable funcionar

Quando comecei minha carreira em tecnologia bancária nos anos 80, eu trabalhava inicialmente com mainframes.

Naquela época, tínhamos equipes de “usuários de negócios da matriz” que especificavam nossos requisitos. Estes eram intermediários que representavam os usuários reais do sistema. Não tivemos contato direto com os usuários reais.

Alguns anos depois, o banco queria testar o que hoje seria chamado de ágil, mas naquela época era o Desenvolvimento Rápido de Aplicativos. O objetivo era acelerar a forma como entregamos nossas soluções. Fomos os primeiros em TI a estar armados com laptops e até telefones celulares. Fomos retirados do escritório de TI e nos deram um escritório em uma das unidades de negócios.

Ao mesmo tempo, fomos autorizados a trabalhar em casa ou em qualquer lugar que sentíssemos que poderíamos ser produtivos. Minha agenda era tipicamente acordar às 6h e codificar até as 2h, depois pausar para almoçar e descansar à tarde. Eu estava de volta à minha mesa por volta das 6h/7h e normalmente codificava até a meia-noite. Isso funcionou para mim.

Além disso, a maior mudança foi realmente obter os requisitos dos usuários finais nas filiais. Isso fez uma enorme diferença para obter a usabilidade e as funções da solução corretas.

Avanço rápido de 30 anos e esta é a norma agora. Nos últimos 30 anos, vimos uma crescente integração de usuários de negócios e TI. Até mesmo os fornecedores de software adotaram um modelo em que os clientes estão profundamente envolvidos em novos produtos.

No entanto, geralmente para requisitos específicos de negócios, um analista os documenta e um desenvolvedor escreve o código. Este é o modelo há décadas.

Houve tentativas de mudar isso, para capacitar os usuários de negócios a escrever suas próprias soluções usando soluções de código baixo ou sem código. De fato, minha última empresa, edgeIPK, foi pioneira na criação de uma plataforma sem código para o desenvolvimento de aplicativos web/móveis. O Gartner chama os usuários de tais ferramentas de “desenvolvedores cidadãos”. Isso reduziu a separação de requisitos e desenvolvimento, mas ouso dizer que gerou muitas soluções difíceis de manter e fomentou pouca reutilização. Portanto, essas ferramentas não foram realmente usadas em nível empresarial para soluções de missão crítica.

No entanto, isso pode mudar com o banco composable, onde a ênfase é desenvolver, publicar e consumir blocos de construção de um mercado e, em seguida, permitir que outra pessoa “componha” esses blocos em uma solução completa. Mas claramente não é tão simples assim. Yefim Natis, analista de vice-presidente e pesquisador do Gartner, define as cinco funções a seguir no banco composable:

1. Arquiteto corporativo (EA): alguém que governa a solução geral em alto nível, garantindo a máxima reutilização e consistência. A arquitetura BIAN é um bom exemplo de algo que um EA pode criar. O BIAN fornece um ótimo modelo para a aplicação de “building blocks” combináveis ​​para uma arquitetura bancária completa.
2. Criadores: desenvolvedores que criam e publicam os blocos de construção de computação individual, funcionalidade ou capacidade de negócios.
3. Curadores: um papel para gerenciar a “biblioteca” ou mercado de blocos de construção. Esta biblioteca também deve incluir quaisquer soluções proprietárias ou adquiridas de terceiros.
4. Compositores: equipes que compõem uma solução a partir de blocos de construção, utilizando plataformas e ferramentas de composição de aplicativos, mas não necessariamente.
5. Consumidores: os usuários reais do aplicativo.

Para obter mais detalhes, consulte o recente webinar de Yefim, 'The Core Principles of Composability: Thrive Through Business Change'.

Estou apenas dizendo que “composable banking” não é apenas uma questão de TI, pois envolve os usuários de negócios. Não é apenas um desenvolvimento padrão com uma biblioteca de reutilização, é uma mudança organizacional, e as empresas terão dificuldades para ver todos os benefícios sem essa mudança.

No passado, o papel de um arquiteto corporativo era extremamente difícil, pois exigia um forte conhecimento do negócio e da tecnologia, para poder filtrar centenas, senão milhares de sistemas e fornecer um plano para um cenário melhor. A BIAN tornou isso imensamente mais fácil, embora a tarefa de mapear os sistemas existentes ainda não seja tão fácil.

Como destaquei em postagens anteriores, o composable banking pode resolver uma série de problemas para os bancos, mas exigirá uma mudança organizacional e deve ser apoiado por uma estratégia de educação e adoção de uma nova forma de trabalhar apoiada por novos papéis. Como sempre, as ferramentas e a teoria estão prontamente disponíveis, o diabo está nos detalhes. Existem fortes exemplos de organizações fazendo este trabalho, e espero escrever sobre eles em breve.

Sobre o autor

Dharmesh Mistry atua no setor bancário há mais de 30 anos e está na vanguarda da tecnologia e inovação bancária. Desde os primeiros aplicativos de internet e mobile banking até inteligência artificial (IA) e realidade virtual (VR).

Ele tem estado em ambos os lados da cerca e não tem medo de compartilhar suas opiniões.

Ele é o CEO da PergunteHomey, que se concentra na experiência para famílias e um investidor e mentor em proptech e fintech.

Siga Dharmesh no Twitter @dharmeshmistry e LinkedIn.

Leia todas as suas reflexões “Estou apenas dizendo” SUA PARTICIPAÇÃO FAZ A DIFERENÇA.