Ep. 155 - Revolução na Arquitetura de Software: como matar um sistema legado

A gente vai falar de um tema técnico, mas conectado muito a negócios. Passamos em diversos clientes e vemos diversos padrões e antepadrões quando a gente tenta matar um legado. Quem nunca precisou matar um legado? Eu fui CTO do PagSeguro durante bastante tempo, fui diretor no UOL, CEO do Boa Compra, que é um meio de pagamento internacional do PagSeguro, e CEO do Mercado Financeiro. Vivenciei um exemplo importante de migração de arquitetura, evolução de arquitetura. Trabalhei na PAG por três anos e consegui acompanhar esse processo, que foi um processo de muito sucesso, dessa mudança de arquitetura, de matar o monolito, mas com um propósito muito conectado ao porquê que a gente estava fazendo o que estava fazendo. A gente sabia porquê que a gente estava fazendo aquilo. Isso acho que foi um dos motivos pelo qual teve tanto sucesso.

Quais são os motivos pelo qual uma empresa deve tentar substituir um sistema legado? O primeiro ponto: o negócio tem que estar sofrendo de alguma forma, de forma clara, visível, sensível a todos. Substituir simplesmente por um desejo técnico, um desejo de testar uma nova tecnologia ou de usar um novo framework que acabou de sair, isso certamente não justifica mudar ou tentar transformar a arquitetura. A arquitetura basicamente são aquelas coisas que definem como o seu sistema vai ser. São difíceis de mudar. São decisões que você gostaria de ter tomado certas no começo do projeto. Mas como tudo muda, fatalmente, em algum momento, se você não tiver sucesso suficiente para ficar ativo por um longo tempo, ela vai ter algum tipo de desencaixe entre o que foi inicialmente feita para fazer e o que faz agora. Isso sem assumir que o time cometeu violações ou incorreu em dívidas técnicas conscientes, que também causam esses gaps.

Eu gosto de classificar em três categorias. A primeira seria algum tipo de impacto em negócio. A segunda seria alguma motivação técnica mais justificável: uma tecnologia que não é mais suportada, um componente comercial que chegou no fim da vida de suporte, um componente open source que não está sendo mais suportado pela comunidade, algum problema de segurança ou de escala. Coisas que mostraram que não vão mais suportar. E o terceiro ponto são questões organizacionais. Se o seu time cresceu muito e a arquitetura é muito acoplada e você precisa ter mais paralelismo no desenvolvimento. Ou se os conceitos estão muito próximos e você precisa aumentar o desacoplamento para permitir desenvolvimento paralelo mais eficiente. Ou se uma empresa fez uma cisão, separou de uma empresa mãe, como aconteceu com o PagSeguro. Ou se adquiriu outra empresa e vai ter que fazer uma integração. No fim do dia, tudo são questões de negócio.

Uma referência que muita gente de TI acaba seguindo é o Gartner. O próprio Gartner já fala há muitos anos que a arquitetura deixou de ser uma coisa só de arquitetura de TI. Os negócios hoje são digitais. O que roda sem sistema por baixo? Dinheiro não existe há muitos anos, dinheiro todo digital. Se você não pensar a arquitetura nesse viés de negócio, pensando o todo, os impactos e alavancas que você tem que mexer para não quebrar o negócio ou a experiência do cliente, não estamos mais discutindo aquela visão simplista de caixa preta. O arquiteto cada vez mais tem que estar conectado com o negócio, entender o problema que está se propondo a resolver, os aspectos funcionais e não funcionais, as características arquiteturais. Tem que ser considerado para se pensar em uma arquitetura e como isso muda ao longo do tempo.

Aí vem um ponto interessante: mas isso não é ágil, porque você está fazendo uma mudança de arquitetura. O ideal seria que a arquitetura nunca ficasse muito distante do problema que ela deveria resolver, colocada organicamente junto com os backlogs e o time. Infelizmente, essa não é a realidade. Muitas vezes você parte de uma arquitetura que não foi concebida para ser evolutiva. E muitas vezes você não consegue que os times priorizem organicamente as atividades nos seus backlogs. Quando você se dá conta, essa distância já está muito grande. Se você começar a fazer isso agora organicamente, nunca vai fechar esse gap. É nesse contexto que a gente trata a revolução de arquitetura. Evolução seria algo que evolui naturalmente com os backlogs dos times. Uma revolução ou transformação é uma iniciativa dedicada, em que existem pessoas dedicando tempo de forma exclusiva. Podem ser alguns times ou vários times, trabalhando tempo parcial, mas há uma dedicação. O objetivo é sair de um ponto da arquitetura e chegar em outro, em que ela atende, deixa de ter aqueles déficits identificados.

Lembro de você, Marlen, indo nos andares e dizendo pra todo mundo por que era importante matar o monolito, com números, com gráfico. Está crescendo, a cada ano a gente exponencializa o negócio, e o sistema não vai ter disponibilidade, não vai permitir a escalabilidade que a gente precisa. As pessoas se olhavam feio quando alguém dizia que ia fazer no legado, porque sabiam que quanto mais alimentasse o legado, mais coisa ia ter que fazer pra criar o novo. A gente tem que falar de uma maneira fácil, com números, visual, que qualquer pessoa vai conseguir entender por que está matando esse legado. A gente passa em diversos clientes em que isso se perde ao longo do caminho. Começam porque vão trocar por uma nova tecnologia que vai permitir inovação, ficam anos criando um novo projeto, às vezes não conseguem entregar nada ou vão entregando pequenas coisas, e de inovação não tem nada, é só uma cópia das features antigas.

Um dos padrões que a gente capturou é a conscientização contínua. A gente tem que manter todo mundo alerta o tempo todo sobre os problemas da arquitetura legada e pra onde a gente está indo. O monolito não é um antepadrão como muitas pessoas parecem achar porque leem sobre migrar pra microserviço. Da mesma forma que microserviço não é um padrão correto sempre. No nosso caso, a arquitetura que tínhamos já era uma reescrita de uma arquitetura anterior em .NET, feita de forma Big Bang. O antigo continuava evoluindo porque não podia ficar parado, mercado competitivo, concorrência surgindo. O novo tinha que correr atrás de um alvo móvel. Demorou um ano e nove meses, o plano inicial era oito, nove meses. Foi um rollout traumático. A gente tinha em mãos um sistema monolítico, recém-feito, com todos os problemas que um sistema novo traz. Mas a equipe tinha 12 pessoas, no final tinha duas. Por ser feito por uma equipe enxuta e coesa, a Lei de Conway atua: por que fazer um sistema distribuído se você só tem 12 pessoas sentadas juntas? Saiu algo monolítico e não estava errado. Usando boas práticas de engenharia de software, com teste automatizado, bastante reuso. Ele atendia aquele momento, aquele contexto.

Ao longo do tempo, o time cresceu algumas ordens de magnitude. O PagSeguro, em 2013, passou a ser também meio de pagamento presencial, com maquininhas, o que mudou muito os requisitos de disponibilidade e tempo de resposta. Depois viramos banco, fizemos várias mudanças de negócio. Mudou o negócio, mudou o tamanho do time, mudou a plataforma tecnológica, de web para terminal, app. O volume de transações e novos clientes também cresceu. Tudo isso motivou a mudança.

O despertar tem dois pontos. Primeiro: a criatura não vai nos levar aonde queremos ir, ela não está nos suportando como deveria, tem problemas. Segundo: nesse ritmo que estamos trabalhando hoje, não vamos conseguir reverter essa situação sem uma iniciativa dedicada. Essas duas condições têm que estar presentes pra perceber que a gente precisa dessa revolução. O que a gente está fazendo é destilar esse conhecimento em padrões, melhores práticas, para líderes que precisam transformar a sua arquitetura. A dor desse líder que se vê nessa situação é o que a gente tentou endereçar.

Duas características que diferenciam a visão evolutiva em cima da arquitetura colada no negócio: a visão é estratégica, olhando para onde o negócio está indo. O negócio hoje já não é mais só pagamento online, já virou maquininha, já tem taxa de transação, tempo de latência menor. Se eu disser que a solução arquitetural do monolito foi ruim, estaria mentindo, porque atendeu aquele problema daquele momento. Mas conforme o tempo passa, o alvo está móvel, aparecem fatores novos. Quando você cria a pista paralela, o objetivo passa a ser entregar o novo sistema, e você mergulhou na solução, deixou de olhar para o problema. Embrace change, responder à mudança, é um dos valores da agilidade, e é uma das paradas que mais se vê ferida numa visão arquitetural de entregar a solução X. A TI se desconecta do negócio porque abaixou a cabeça para entregar o que foi prometido, em vez de trabalhar em fatia. A coisa é: a gente quer crescer, tem oportunidade, mas se a gente não revolucionar, isso tem valor de negócio mensurável. O lead time não vai cair se a gente não fizer essas mexidas. Agora estamos falando a mesma linguagem, batendo no ponteiro de negócio.

O primeiro padrão é todos no mesmo barco. O ponto de partida para ter mais chances de sucesso numa jornada de transformação de arquitetura é trazer negócios para dentro. Porque se você fechar a portinha da área da TI e ficar trabalhando seis meses, nove meses, um ano, além de poder sair com uma solução que não é mais a que você precisa, a percepção das outras áreas da empresa é de desperdício. A arquitetura não é uma coisa de TI que TI inventou e TI tem que resolver. É a soma de decisões tomadas ao longo do tempo. A situação afeta todo mundo, afeta todo o negócio. Não dá para enfiar debaixo do tapete, dizer que TI se vira. Vai ter que ter uma disciplina dedicada, gente trabalhando nisso, mexer em backlog, afetar entregas. Para isso acontecer bem, todo mundo tem que estar no mesmo barco, entendendo que não é eu e vocês, é todo mundo junto.

Um outro padrão é dar um susto neles, em inglês, scare the ass out of them. Reunir dados, reunir fatos, para mostrar que vai dar problema se a gente não mexer. Esse padrão tem o seu downside: pode colocar a sua carreira em risco, porque vai mostrar muita coisa feia, muita coisa suja. Dependendo da cultura da empresa, isso pode ser visto como punitivo. Sem coragem, você não cresce na carreira. Não fazer, não falar, não ser claro no que é um problema de fato, é se rebaixar, é conviver com a janela quebrada, um ambiente que vai ficar imundo. É diferente de esconder do de eu vou, mas essa briga a gente não quer brigar agora. São duas coisas bem diferentes. Se a decisão for consciente, entender que não vamos mexer agora, é diferente de jogar o jogo de forma irresponsável, postergando algo que quanto mais demorar, pior fica.

Um líder não seria responsável de chegar para a alta gestão e falar que tem problemas sem ter um plano na manga. A pergunta natural do executivo é: mas e aí? É a hora de vender a ideia. Se não tiver um plano, perde a oportunidade e passa por irresponsável. Isso se liga na visão de arquitetura, que é uma ponta mais técnica. A sugestão é que a visão esteja muito conectada aos porquês, traga os critérios de sucesso, como se mede que o que está propondo vai resolver o problema.

Na jornada do PagSeguro, a gente começou a medir várias coisas, até antes de começar a transformação. Isso foi fundamental para dar segurança. O ideal é que o cliente não perceba a mudança, mas é importante que a gente dentro da empresa tenha esse pulso. Um padrão importante é pavimenta o caminho, para que os times tenham mais eficiência em mudar a arquitetura, trabalhem em cima de uma base de ferramentas e componentes. Uma frase do nosso CIO: tem que ser mais fácil seguir o padrão do que reinventar roda. Os padrões ligados à medição incluem métricas para baseline e comparação, muito conectado com fitness functions. Métricas de tempo de resposta, disponibilidade, a gente usou muito o APDEX, que mede respostas respondidas dentro de um certo tempo sobre o total de respostas com sucesso. Métricas de desenvolvimento, lead time para entrega de features, qualidade de código. No PagSeguro, usávamos a quantidade de commits e linhas de código novas e committers diferentes no monolito. A gente não queria que o pessoal mexesse no monolito, exceto para projetos que estavam tirando do monolito. Depois a gente travou totalmente. Isso era uma métrica para saber se o time estava conseguindo trabalhar na nova arquitetura ou sendo forçado a usar a antiga.

A gente passou a trabalhar essas evoluções com o mindset de produto. Qual problema eu quero resolver? O que eu quero medir? Foi, melhorou, não melhorou, o que está acontecendo ainda? Criou um ciclo de build, measure, learn numa coisa que antigamente a gente desenhava um plano de dois anos e botava a peonzada para moer a carne. Não faz o menor sentido. Um dos padrões trata a revolução arquitetural como um portfólio ágil, porque em qualquer empresa não trivial, você vai ter vários times trabalhando nisso. No nosso caso, tinha dezenas de times, quase centenas. Alguém tinha que ter o papel de Agile Portfolio Manager, reunindo o progresso de vários times, fazendo facilitações, trazendo alertas antecipados.

A empresa escolheu definir metas ligadas à arquitetura. Isso foi uma decisão do nosso dono, o Luiz Frias. A sacada foi que a meta não foi só tecnologia, foi resultado de uma venda contínua ao longo de muitos anos. A meta virou da empresa inteira. Até gente do financeiro, do corporativo do UOL, tinha essa meta. Me ligavam para falar de orçamento e aproveitavam para perguntar o progresso. Isso contagiou muito o time, trouxe engajamento. Quando virou meta e entrou como questão de bônus, gerou visibilidade enorme. Poderia ser um OKR, algo não ligado a bônus, mas nesse caso foi, e a gente viu a potência que isso traz.

O desafio é como comunicar uma coisa tão técnica para tanta gente. Veio uma sacada do time de inovação e design. A gente criou um Lego gigante com 30 peças, cada uma representando um fluxo que afetava o cliente. A gente se comprometeu a mudar 30 fluxos. Toda vez que tirava um fluxo do monolito, tinha uma cerimônia: o time ia lá, tirava a peça, tirava foto, gravava, fazia entrevista, um show. Isso motivou demais os times que estavam trabalhando e os que estavam de fora, porque viam e torciam. Pessoas que nem eram de tecnologia estavam ali torcendo. É awareness contínuo, porque você gerou um símbolo. A gente começou a tirar só em julho, agosto, e foi até o final do ano, com uma última entrega entre Natal e Ano Novo. Chamamos de torne o progresso tangível. Sempre que fazia uma entrega no monolito, gravava um screencast na madrugada, mostrando que aquele fluxo estava fora, mas funcionava. Publicava na plataforma interna e o pessoal adorava ver.

Essas metas estavam conectadas ao resultado, não à entrega em si. A gente tinha dois tipos de meta. Uma era a entrega dos itens, com critério de sucesso de entregar aquele fluxo fora do monolito. Mas por que isso gerava valor? Porque o monolito tinha problemas de disponibilidade. Se eu pego fluxos de valor para o usuário, como uma tela que ele via ou um fluxo interno de liquidação que afetava quando ia chegar o dinheiro na conta dele, e coloco como meta migrar para a nova arquitetura, estou transitivamente chegando à melhor disponibilidade no valor. O outro componente era o APDEX, uma meta para o aplicativo, e metas de disponibilidade ligadas à adquirência, liquidação, conciliação. No artigo, a gente fala de dois tipos de alvos: alvos de entrega e alvos de saúde, que garantem que você migrou para uma nova arquitetura sem prejudicar o usuário, ou até subindo a barra de qualidade de serviço.

Quais são os possíveis approaches? Além dos blocos de criar consciência e preparar e medir, tem padrões ligados a como priorizar e como organizar os times. A visão arquitetural dá a direção, a essência do que é a nova arquitetura, o que tá ok fazer, o que não tá ok. Dois padrões importantes: freeze, que é congelar pra mexer na arquitetura. O LinkedIn fez isso, o projeto Inversion, parou a empresa por três meses, quase quatro, só pra mexida de arquitetura. Para times menores pode funcionar. A outra abordagem é trocar o pneu com o carro andando: não parar o que tá sendo feito, mas incluir times novos e atividades em times existentes para que a revolução aconteça sem afetar muito as prioridades de negócio. Afetar zero é possível com mais recursos, mas algum time vai ter que mexer no seu componente. Tem que ter big steps, passos curtos, buscar quick wins, os retornos rápidos, trazendo componentes mais críticos ou que trazem muito impacto pro usuário.

Um padrão é espelhe a feature da nova arquitetura. Funciona bem quando você tem uma funcionalidade que vai ser muito difícil criar a nova arquitetura sem mudar o front. Você espelha aquela feature na nova arquitetura, com infraestrutura nova e front novo, de um jeito que sejam duas coisas paralelas. O cliente pode voluntariamente escolher a nova tela e ir e voltar. Tem que ter os dados embaixo se comunicando. Se você está forçando o cliente para um caminho sem volta, não é uma boa usar esse padrão. No PagSeguro, a gente fez várias migrações mantendo a tela equivalente à anterior, mas com a nova arquitetura embaixo. O cliente não percebia uma disrupção, no máximo uma melhoria de eficiência. Quando a gente já estava migrando para o novo design system, colocou no novo design system sem tirar nenhuma feature do cliente. Se der problema, faz rollback, volta à tela antiga com o sistema antigo.

Tem que ter a arte de não fazer a mudança ser grande demais, porque se for grande demais, sem querer, vai virar um all-in, um freeze. É muito fácil num olhar arquitetural, já que vou ter que mexer nisso, mexe naquilo, e daqui a pouco você já tá num projeto de um ano e meio. É o jaquê. Tem que evitar o jaquê, fazer baby steps, implantar a nova arquitetura, colocar a base e ter vitórias rápidas. As vitórias rápidas vão ser rápidas se você diminuir o escopo e mostrar essas vitórias pra todos. Isso também te ajuda a validar a arquitetura. Componente pronto é componente em produção, sempre. Quando você coloca no ar e vai tendo times usando, tem que ter acompanhamento muito próximo, eles são seus beta testers. Tem que garantir que tá saindo suave, que os resultados tão vindo. É fatiar e ver rápido os potenciais problemas.

Certo e errado é um julgamento muito contextual. É perigoso dizer que o freeze tá sempre errado ou a pista paralela tá sempre errado. Existem dois níveis de visão. O primeiro é o nível estratégico, quando a gente cria a narrativa dos porquês, os porquês de negócio, e normalmente traz o board de executivo junto. O segundo nível, de priorizar atividades, é mais micro, backlog de produto, o que os times vão trabalhar nos próximos meses. Já não interessa o board executivo inteiro, mas um diretor de negócio mais envolvido. É muito importante separar isso, porque se a de cima não tiver comprada, a discussão embaixo vai ser sobre prazo, entrega, é um inferno. Esse trabalho de formiguinha e contínuo, de conscientização, manter o reporte, manter o progresso tangível, dá um trabalho brutal. Não é ágil, é prático, você tem que fazer.

A gente separou em priorização estratégica e priorização tática. A gente não se compromete com nenhuma arquitetura específica, não é só monolito pra microserviço, poderia ser o sentido inverso, qualquer service-oriented architecture, evento, qualquer outra coisa. Um padrão importante que a gente fez no PagSeguro foi limitar as mudanças no legado. Colocou um gateway, uma limitação do que poderia ser feito no legado, com um CAB, Change Advisory Board. Todo mundo começou a comentar: vai precisar da aprovação do Marlen pra mexer no legado, que absurdo, centralizador, não é ágil. Mas depois que começou a rodar, o pessoal começou a elogiar. É não renunciar à liderança. O jeito que foi feito foi bom: não era o Marlen provando, era a gente entendendo que você quer resolver esse problema, mas você já tentou falar com tal pessoa, já tem isso pronto em tal lugar. Rodou o CAB por três anos. Nesses três anos, só me lembro de uma iniciativa que a gente negou, e era uma coisa que ia realmente engrossar o monolito e não via valor suficiente. As negativas eram: volte com mais detalhes, volte com um plano melhor, era um convite pra pensar. Essa que a gente negou voltou pra prancheta e voltou meses depois sem usar o monolito, de um jeito mais fácil e mais rápido. Todo o resto foi no sentido de questionar, de ajudar. O time que participava do CAB, os especialistas do monolito, davam tanta ajuda que o pessoal literalmente gostava. Transformou uma coisa que parecia negativa em reforço positivo.

Esse conjunto de padrões é experimentado em campo, não nasceu desenhado da cabeça. É engenharia reversa do que a gente fez pra dar certo. Funcionou no lugar. O trabalho do Marlen e do Joe vem antes da discussão em team topologies, e é importante porque muita gente entra na discussão de team topologies despreparada, não sabe o porquê de negócio, e o enabler vira o famoso entrega o projeto. Se você não sabe o que quer gerar de resultado, o enabler vai virar disfunção. Deem uma olhada no artigo, é um baita trabalho pra se seguir.