Blog

Olá, BANCOS! Precisam mesmo de outro Core Banking System?
Software
Oct 12, 2019
Olá, BANCOS! Precisam mesmo de outro Core Banking System?
As nossas mentes estão formatadas para assumir sem questionar que os sistemas tecnológicos que envolvem operações complexas e críticas são sempre algo desenvolvido de forma secreta e gerido por pseudocientistas de um filme de Hollywood dos anos 80. "Complexidade é o inimigo da execução" Atualmente, na nossa sociedade, como resultado dessa visão comum, nas áreas de negócios mais tradicionais, é muito raro questionarmos "por que precisamos de tanta complexidade?". Depois de vários anos a trabalhar em arquiteturas de software complexas para instituições financeiras e desde 2017 como fundador de uma Fintech e empresa de Software, acredito verdadeiramente que todos os bancos tradicionais são o melhor exemplo da famosa citação de Tony Robbins sobre a complexidade: "complexidade é o inimigo da execução". A principal razão para esta conclusão foi identificada e é amplamente reconhecida por todos os profissionais de serviços financeiros: estamos a falar da dependência dos sistemas obsoletos. O meu objetivo, quando decidi escrever este artigo, não foi falar sobre os problemas de sistemas antigos obsoletos, lentos ou inseguros, mas sim partilhar a minha conclusão perturbadora de que os responsáveis pela estratégia de evolução tecnológica desses bancos estão a repetir os mesmos erros antigos quando tentam remover da equação os seus sistemas atuais. Dependência de um único componente, geralmente vindo dos anos 80 e 90, que chamamos de Core Banking System O que está a causar que a maioria dessas organizações esteja condenada a desaparecer num período mais curto do que podemos imaginar? A resposta é a sua dependência de um único componente, geralmente vindo dos anos 80 e 90, que chamamos de Core Banking system.A maioria dos Core Banking Systems foram desenvolvidas para oferecer todas as funcionalidades necessárias para gerir um banco. E UAU... isto foi ótimo para quem queria ter um banco em funcionamento rapidamente! Nos anos 80 e início dos anos 90, não existia internet acessível para todos, nem existiam empresas Fintech a revolucionar o mercado, e a maioria dos produtos bancários eram idênticos entre os bancos. Os verdadeiros desafios de operar com um Core Banking System antigo surgem quando os processos de negócios da organização começam a abrandar sempre que são necessárias pequenas alterações no sistema, quando é necessário suportar soluções de canais numa corrida para a transformação digital do banco, responder rapidamente a mudanças regulamentares obrigatórias ou implementar personalizações específicas para introduzir um novo produto no portfólio. A analogia do amante da música vs o profissional da música Recentemente encontrei a analogia perfeita para este processo de modernização do Core Banking. O amante da música vs o profissional da música.Deixa-me explicar a minha analogia. Se gostas de ouvir música em casa e não precisas de equipamento de som para viver, podes comprar um hi-fi ou até mesmo usar o hi-fi dos teus pais dos anos 90. Se precisares de reparar algo no hi-fi antigo, será difícil encontrar um bom técnico barato, e algumas peças podem ser difíceis de encontrar, mas o ponto é que tu não és um profissional, gostas de ouvir música relaxante no fim de semana, e este hi-fi antigo serve para o que precisas! Isto é o que muitos dos bancos tradicionais que não estão a investir em inovação estão a fazer, estão simplesmente a ouvir música e inconscientemente à espera do seu fim.Mas se fores um músico profissional ou um DJ, terás concorrência e precisas de manter o teu sistema atualizado, se possível com um sistema de última geração, para poder competir no mercado com outros músicos. Neste caso, não irás comprar um hi-fi "doméstico", mas sim vários módulos de hardware de som profissional separados e cabos de alta qualidade, todos com interfaces padrão para poder rapidamente atualizar ou simplesmente mudar parâmetros de som para melhor responder e adaptar-se ao espaço onde estás a tocar.Este tipo de sistema é difícil de montar, mas, uma vez estabelecido, torna-se significativamente mais fácil de adaptar a qualquer necessidade ou cenário. A imagem à esquerda é, na minha opinião, a analogia perfeita para representar uma camada de integração robusta e muito personalizável de um banco moderno, onde podemos conectar dezenas ou centenas de módulos externos, orquestrando e ajustando todos os resultados finais. Quando um banco com esta visão moderna de Arquitetura de Sistemas adquire ou desenvolve um novo módulo para integrar no seu ecossistema de microserviços, já sabe que será fácil substituí-lo no futuro, porque foi desenvolvido com a integração e o isolamento de domínio em mente e, esse é o ciclo normal de vida dos módulos tecnológicos na indústria financeira ultrarrápida de hoje. No final, trata-se de ser um músico profissional ou simplesmente alguém que gosta de música e tem uma caixa de som hi-fi, afinal, tudo se resume ao resultado final. Por que os bancos estão a substituir antigos sistemas monolíticos por novos sistemas monolíticos? Uma das questões mais difíceis para eu responder hoje em dia é porque é que os bancos estão a substituir sistemas monolíticos antigos por novos sistemas monolíticos? Mesmo que os novos sistemas sejam construídos com ferramentas mais modernas, utilizando arquiteturas de hardware menos proprietárias ou até mesmo executados na cloud, isso não resolve os problemas estruturais subjacentes. Só porque um fornecedor mostra alguns exemplos de serviços de integração, como APIs de serviços web, ou apresenta um catálogo de produtos com módulos separados, não significa que não esteja a comprar outro monólito! Nos últimos 8 anos, tornou-se cada vez mais comum ver bancos a substituir o seu Core banking System por um novo Core Banking System moderno. No entanto, a razão por trás dessa escolha é que a maioria dos Bancos não tem na sua equipa de gestão um verdadeiro engenheiro, ou engenheiros com uma visão limitada de arquitetura de sistemas, ou na maioria dos casos as decisões são tomadas sem o feedback da equipa de engenharia. Para os responsáveis pela decisão com um grande ego, e com medo da evolução tecnológica, a escolha mais segura quando se trata de fazer grandes investimentos em transformação tecnológica é sempre adquirir sistemas caros e de fornecedores de grande nome. Normalmente, como resultado de um ou mais relatórios feitos para eles por uma das grandes cinco consultoras, que têm um enorme interesse comercial em manter sistemas proprietários, fechados e, especialmente, difíceis de adaptar, para continuarem a vender contratos exorbitantes de desenvolvimento, análise, consultoria, etc.Os decisores devem concentrar-se no verdadeiro problema: a falta de liberdade para gerir e controlar o seu percurso tecnológico, que é a base do ritmo acelerado e do baixo custo de manutenção de quase todas as empresas Fintech. A essência do monólito vive nesse lado obscuro, onde o fornecedor do sistema interliga, na mesma base de código, todas as regras de negócio de diferentes áreas de domínio. A alma dos sistemas monolíticos está presa neste lado sombrio, onde o fornecedor do sistema combina todas as regras de negócio num único código, como a famosa “bola de esparguete infernal”. Com esta abordagem, os fornecedores podem afirmar que o novo Core Banking System oferece milhares de serviços de integração (APIs, filas, etc.), mas todos os problemas antigos permanecem. No final, estão apenas a vender um novo monólito, agora suportado por linguagens de programação modernas e instalado em infraestruturas de hardware padrão ou na cloud. O segredo para o sucesso neste processo de modernização está em libertar a organização da dependência de um único fornecedor. É crucial evitar ficar refém de sistemas que exijam suporte contínuo do mesmo fornecedor ou de empresas de consultoria dispendiosas para realizar, analisar ou executar todas as tarefas necessárias para que a organização opere os seus sistemas de forma eficaz. Arquitetura de Microserviços é o caminho para a modernização e acelera todas as mudanças de negócios e evolução dentro de um banco. Todos os sistemas dentro do banco devem respeitar os padrões da indústria em termos de estruturas de dados de entrada e saída, isolando pequenas funções de negócios ou integração em módulos de software separados. A Arquitetura de Microserviços é o alicerce para a modernização e a base para todos os processos de mudança e evolução de negócios num banco. O meu conselho para os responsáveis pela tomada de decisões na indústria financeira é que compreendam que o ativo mais importante dentro da organização são os seus dados. Não devem depender de um único grupo de fornecedores para gerir e aproveitar o poder dos dados, de forma a garantir que a organização continue a gerar oportunidades de negócios e de mercado. Arquitetura de sistemas é a base da flexibilidade da organização para se adaptar rapidamente às necessidades do mercado Aqueles responsáveis pela tomada de decisão que ainda não perceberam que o investimento em tecnologia não tem de ser um investimento em fornecedores específicos de grandes nomes, e que a Arquitetura de Sistemas é a base da flexibilidade da organização para se adaptar rapidamente às necessidades do mercado, serão responsáveis pela perda de clientes e, em muitos casos, pelo fim da organização. Nestes casos, a aposta "segura" nos fornecedores de renome não valerá nada como defesa.
Pedro
Pedro Camacho
CEO & Co-founder
Azure Active Directory — Authentication OAuth 2.0
Software
Jan 08, 2018
Azure Active Directory — Authentication OAuth 2.0
Nas últimas semanas, estive a trabalhar num serviço de integração para um sistema complexo baseado no Azure. O meu objetivo era encontrar uma forma de autenticar no Azure Active Directory, basicamente obtendo o token de acesso para as futuras requisições ao sistema, sem o pop-up de login da Microsoft, muito comum em integrações com serviços como Facebook e outros. O Microsoft Azure Active Directory (AD) já possui uma biblioteca de autenticação (ADAL), mas, infelizmente, não existe suporte para a linguagem que eu estava a utilizar no momento, GoLang. Diante desta situação, fui obrigado a encontrar uma solução alternativa. OAuth 2.0 OAuth 2.0 é um protocolo de autorização que permite que as aplicações obtenham acesso limitado às contas dos utilizadores num serviço HTTP. Não vou explicar todos os detalhes do protocolo aqui, o que vou me focar são nos grant types de autorização.OAuth 2.0 tem quatro grant types: Password; Client Credentials; Implicit; Authorization Code.  Com esta informação e para resolver o meu problema, escolhi o fluxo de autorização Password Grant. Para cenários semelhantes, quando se confia em clientes internos (first-party) ou de terceiros (third-party), tanto na web como em aplicações nativas, esta abordagem oferece ao utilizador final a melhor experiência. Para mais informações sobre o OAuth 2.0, podes consultar aqui. Microsoft Azure Active Directory e OAuth 2 Neste ponto, comecei a procurar como usar o tipo de fluxo Password Grant no Azure AD. A documentação da Microsoft não é muito útil nesse caso. Eles focam-se nos outros fluxos de grants usados em diferentes cenários, como: Authorization Code para aplicações Web Server; Implicit Grant para aplicações nativas; Client Credentials para aplicações de serviço.  No entanto, o tipo de fluxo Resource Owner Password Credentials Grant também é suportado desde a versão 1.1 no Azure AD. Este fluxo também é baseado em pedidos HTTP, mas sem redirecionamento de URL. Para mais informações sobre este fluxo, podes consultar aqui. Assim, para este caso específico, quando temos um serviço de integração, como um windows service, para obter informações de uma aplicação que requer autenticação, esta abordagem é prática e eficiente. Como usar Para usar esse método e obter o token no Azure AD OAuth 2, precisamos fazer a seguinte solicitação de serviço web:https://login.microsoftonline.com/<TenantId>/oauth2/token Content-Type: application/x-www-form-urlencoded Host: login.microsoftonline.com TenantId: <MY_HOST> (for example “mywebsite.com”) WS: /oauth2/token Parâmetros a utilizar no Body request: grant_type: password client_id: O valor do Client Id do Azure AD resource: O valor do App ID da aplicação para a qual deseja um access token client_secret: O valor do Client Secret do Azure AD username: O nome de utilizador de uma conta no Azure AD password: A password da conta do utilizador Resultado do request: HTTP/1.1 200 OKContent-Type: application/json; charset=utf-8{ "token_type":"Bearer", "expires_in":"600", "expires_on":"1511533698", "not_before":"1511533698", "resource":"*resource*", "access_token":"*token*","refresh_token":"*token*", "scope":"user_impersonation"} Agora tens o teu token de acesso para usar na tua aplicação. Já tiveste esta necessidade ou tens outra abordagem? Fica à vontade para partilhar. Espero que estas informações sejam úteis para futuros desenvolvimentos! Result access token exampleJá tiveste esta necessidade ou tens outra abordagem? Fica à vontade para partilhar. Espero que estas informações sejam úteis para futuros desenvolvimentos!@medium
João
João Marçal
Digital Products Development Manager

3 / 3