Mas vamos lá, quais são os principais pontos que a gente tem que ter na cabeça quando a gente vai falar de mudar um sistema? Eu vou tentar compartilhar com vocês, tá, gente, um pouco da minha história, um pouco do que eu aprendi, muito mais do que só uma conversa de conteúdo que você consegue até buscar aí na internet. O que eu quero trazer para vocês é um pouco da minha experiência. É fazer vocês não gastarem bala, hoje talvez não faça tanto sentido, e vocês serem mais diretos ao que eu, pelo menos, vi dando certo, tá? Acho que aqui a gente consegue economizar um tempo aí de vida, um tempo de entrega bem grande, acho que o que eu aprendi em sete anos, eu vou tentar trazer aqui pra vocês nesse material, pra vocês conseguirem ser mais eficientes na hora de fazer isso no dia a dia. Então, sendo bem direto, pensem nas coisas que eu tô falando aqui, não é só sobre tecnologia, é sobre tudo. A gente precisa ter uma visão de tudo. Tecnologia é um dos pontos que a gente tá falando aqui. E vocês vão ver que eu vou passar por vários deles. Antes de você pensar, tem um monolito, eu vou quebrar ele, eu vou levar para lá, não sei o que, que é onde a gente normalmente vai, que é na execução, é muito importante você definir os seus objetivos. É bem isso que eu falei. Imagina num monolito que eu tinha ali anterior, eu falasse, putz, eu quero pegar esse cara, eu quero mudar ele, quero levar para a AWS, quero fazer ele com Kotlin, quero deixar ele super desacoplado. Por quê? Quais são os objetivos que a gente quer atingir? Parece uma bobeira, mas se você não tiver os seus objetivos muito claros, você vai falhar. Você vai falhar porque não depende de você. Não depende só do que está na sua cabeça. Às vezes a gente pensa que, por tecnologia, transformar um sistema em um sistema mais moderno já é o suficiente. E eu mesmo já falei transformando um sistema mais antigo num sistema mais moderno e deixando ele com mais difícil manutenção. Vou contar aspas aqui para a gente trocar uma ideia. Teve uma vez que eu fiz uma mudança dessa de um monolito para microserviço, mas em vez de ir para uma visão de microserviço, eu fui para quase nanosserviço. Era um serviço tão pequenininho que na hora de dar manutenção, na hora de entender no dia a dia a troca de mensagens que estavam acontecendo para entender, para fazer um troubleshooting durante o dia, virou um inferno estava muito difícil de fazer e a gente teve que repensar e mudar de novo essa visão de arquitetura para ser um pouco melhor então é muito importante você definir os objetivos que você quer atingir, você mapear quais são os stakeholders que vão participar desse assunto putz, você vai mudar um sistema, mas se você tiver na sua orelha sempre uma gama de stakeholders falando, não, não é para mudar, a gente quer entregar uma coisa nova, para de querer refatorar tal coisa. Vamos mudar, vamos colocar mais coisa aí no que já tem, faz um puxadinho no que já tem e vamos em frente. Você vai ter uma vida horrível e vai criar só mais complexidade. Isso é outra coisa muito importante. Vocês vão ver que eu vou dar vários aspas aqui para contar pequenas histórias. Mas teve um determinado momento na minha carreira que eu estava fazendo um projeto que era claro que era para a gente modernizar o sistema, saindo ele de uma plataforma COBOL e indo para a Java na AWS e a gente começou a criar aqui algumas mudanças para começar a fazer essa migração e no meio do caminho começou a vir tanto projeto e tanta ideia diferente que para a gente fazer na migração e no meio do caminho começou a vir tanto projeto e tanta ideia diferente que para a gente fazer na plataforma nova ia demorar mais tempo porque a gente estava começando a construir que os stakeholders não tiveram paciência ali, eles quiseram fazer isso mais rápido e acabaram pedindo para fazer de volta no COBOL, então a gente ficou com meia plataforma na distribuída no Java, metade da plataforma com COBOL e com algumas peças para fazer uma conversa de uma coisa com a outra, ou seja, só trouxe mais complexidade. Antes eu tinha uma plataforma monolítica no COBOL e agora eu tinha uma plataforma monolítica, outra plataforma sendo replicada na distribuída e ainda tinha que fazer uma coisa falar com a outra. Morfologia de dado para baixo e para cima para conseguir fazer o sistema se conversar. Ou seja, a gente ficou bem mais caro durante algum tempo até a gente entender que a gente não está vindo atrás do objetivo que a gente tinha definido. E que os stakeholders não estavam comprados com aquele objetivo. Então, entenda o objetivo e deixe extremamente comprado com os seus stakeholders. Se não tiver claro o que precisa ser feito, se não tiver claro o que precisa ser feito se não tiver claro como vai ser essa modernização como que a gente vai migrar nos sistemas e como que os stakeholders vão se portar durante este tempo não faz sentido continuar esse projeto, faz sentido repensar se é o melhor momento e etc outra coisa muito importante a gente fala muito de tecnologia, sei lá, vamos fazer em Kotlin vamos fazer em Java, vamos usar Micronaut vamos usar vai fazer com SQS, vai ser mensageria. Antes disso, gente, a gente tem que definir os contextos. É muito bacana você pensar em cachogramas antes de pensar em peças técnicas, você pensar em cara, eu vou ter um contexto de pagamento, mas eu também vou ter um contexto de criação de uma nova pessoa dentro do meu sistema. Eu preciso de um contexto de pessoas, eu preciso de um contexto de pagamentos, eu preciso quebrar, será, pagamento de cartão de crédito, do pagamento via Pix, do pagamento via boleto, tem gente que ainda paga via boleto. Pagamento via carnê, essa é pra quem é mais velho, né? Carnê via boleto, pagamento via carnê, essa é pra quem é mais velho, né carnê acho que só a galera mais antiga vai lembrar, mas vai ter esse monte de tipo de contextos que faz sentido você pensar muito bem antes de sair fazendo pra não acontecer o que eu falei com vocês você não ir pra uma ideia de nanosserviço que vai gerar muito mais dificuldade depois, ou pior, ter contextos cruzados, quando o dia a dia do time ali estiverem tocando depois de modernizado eles vão começar a entender que essa parte é minha ou é da squad do meu lado isso aqui faz parte do meu contexto, é do contexto de pagamento ou sei lá, eu quebrei por um contexto aqui de de trazer pra data atual tentar antecipar o valor isso aí é do contexto de pagamento ou é do contexto de calculadoras ou de antecipar o valor. Isso aí é do contexto de pagamento ou do contexto de calculadoras ou de antecipação. É bacana você ter isso bem definido e tomar cuidado para não replicar, por mais que a gente saiba que isso acontece, tentar não replicar a visão do que tem na sua estrutura organizacional para o seu time. Porque a estrutura também muda, isso é bem importante. Cada vez mais as estruturas, as lideranças e os times, por mais que a gente busque times que estão mais contidos, autocontidos e com menos mudanças, no dia a dia as mudanças estratégicas acontecem e você tem mudanças na organização. Toma cuidado para não fazer o seu sistema se desenhar de acordo com a sua organização. Todo mundo sabe o que acontece, mas vamos tentar fugir o máximo que a gente puder pra gente não cair nessa armadilha também. Porque daí muda o chefe, muda você, muda o outro e aí, quem consegue entender aquilo? Então, pensa no contexto pelo contexto. Recebimento faz sentido estar junto com um contexto de contabilização ou não faz? Se fizer, vamos juntar. Se não fizer, vamos deixar separado. E faz, se fizer, vamos juntar, se não fizer, vamos deixar separado e com as suas fronteiras bem definidas. Uma outra coisa importante é você definir no começo uma arquitetura alvo. Onde a gente quer chegar? Quais serão as divisões que a gente vai ter? Como isso vai se desenhar no futuro e quais são os problemas que isso traz? Se você não sabe quais são os problemas que isso traz, você tem um grande problema. Porque toda arquitetura tem seus pontos fracos. Não dá para acreditar que as arquiteturas vão ser uma bala de prata que resolvem todos os problemas. Se você fizer uma arquitetura orientada totalmente a evento, possivelmente ela vai ter mais complexidade do que uma arquitetura com um pouco de evento, um pouco de requisição direta, com processamentos massivos, etc. Normalmente vai ser mais complexa. Significa que ela é ruim? Não. Significa que normalmente ela tem mais complexidade de tratar ali no dia a dia. É bom você saber o que você está trazendo para a sua arquitetura-alvo e estar comprado com isso. Define uma arquitetura de transição. Para mim, esse é o que ganha o jogo. Porque normalmente a gente desenha uma arquitetura por ser de tecnologia, a gente adora fazer as coisas bonitinhas, né? Eu costumo dizer que a gente, se fosse perguntar pra quem é de TI, pra quem gosta de TI, a gente quer no fim do dia ser o cara que faz aquela peça, aquele artesão, sabe? Faz aquela peça totalmente complexa que só a gente entende, puta bonita, pra pendurar na parede. Então, a arquitetura-alvo, normalmente, ela vai ser um pouco disso. Ela vai ser aquilo que a gente entende que é o supra-sumo do nosso sistema. A gente vai chegar nessa arquitetura-alvo em um mês? Não. E a gente precisa gerar certo valor até para acalmar os stakeholders, para trazer valor, porque é investimento. Você está investindo aqui pesado na sua plataforma, você quer ver se aquilo vai funcionar, até pra ver se você se o que você imaginou de arquitetura algo tá no caminho, porque você pode errar também, né qual a chance que a gente tem de errar? é grande, porque a gente tá fazendo um monte de coisa nova então definir uma arquitetura de transição é muito importante falar, cara, até a gente chegar na arquitetura algo a gente vai conviver desse jeito com o que é novo e com o que é velho, a gente vai conviver com as plataformas assim, a gente vai topar esses riscos, a gente vai topar esse pagar mais caro por ter que processar duas vezes, a gente vai ter que ter algumas discussões aqui sobre arquiteturas de transição, e eu gosto até de fatiar ó, em três meses a gente vai ter essa arquitetura de transição, em seis meses essa outra, em oito meses essa outra, e daqui um ano a gente chega na arquitetura alvo. Isso é extremamente importante para você fazer as suas entregas e conseguir entregar valor mais rápido e para a galera começar a sentir aquele gostinho de que, olha como isso muda. Aqui eu acho uma coisa muito importante. O último projeto que eu fiz, a gente estava com uma consulta de saldo. A gente fazia uma consulta de saldo que ela demorava mais ou menos 14 segundos na arquitetura antiga. Na hora que a gente começou a mudar e tal, eu defini uma arquitetura alva em Coutinho e uma arquitetura de transição. A primeira coisa que a gente entregou foi essa consulta de saldo na arquitetura de transição. E ela baixou pra um tempo médio de resposta, acho que foi o P99 tava na casa dos 86 milissegundos. A estava na casa dos 86 milissegundos. A gente chegou a bater esse P99 100 milissegundos, mas depois a gente tornou, a gente foi até 86 milissegundos. Pô, a gente saiu de 14 segundos para 86 milissegundos. Só isso já trouxe uma percepção para os stakeholders de que olha que legal, o que eles estão fazendo vai trazer outra visão para o nosso cliente. A gente saiu do P99 de 14 e foi no P99 de 86 poxa, olha só é muito diferente, traz muito benefício pro dia a dia, se você não tá acostumado a falar tanto assim de velocidade eu vou pedir um favor pra você, para o vídeo pega o seu celular aí, coloca 14 segundos e fica olhando pra tela dele você vai ver como é a chegada raiva do tempo de demora que é. Não dá pra você esperar 14 segundos pra uma requisição te retornar o seu salvo. Então a gente teve alguns momentos aqui em alguns sistemas que eu trabalhei com uma requisição demorando esse tempo. E a gente diminui pra 86 milissegundos, mostra que a velocidade de resposta é bem maior e a nossa experiência fica bem melhor. Outra coisa, usa o stack como aliado e não como inimigo. Por que eu falo isso? Muita gente fica bitolada em falar, cara, eu quero usar Micronaut, ou eu quero usar Quarkus, ou eu quero usar Kotlin, o que eu quero fazer? Calma, o stack vai ser seu aliado. Se você tentar resolver tudo com o mesmo stack, vai dar errado. Tem momentos que você vai precisar usar Python, tem momentos que você vai precisar usar Java, e tudo bem. Tem momentos que vai fazer sentido você usar um banco de dados relacional e outra vez não vai fazer sentido. Não adianta você querer usar aquele negócio que está hypado, tipo putz, isso aqui é muito legal, todo mundo está usando, eu quero usar também. Vai te trazer mais problemas. Pensa no simples, não pensa no complexo. Trazer as ideias que a gente tem de arquitetura e as ideias que a gente tem de sistema tem que ser sempre para resolver um problema. Você não pode fazer isso porque você gosta daquilo. É para resolver um problema. Uma outra coisa muito importante é, que eu tenho bastante discussão com os times normalmente é, putz, eu quero começar a usar aqui gol, eu adoro gol até o Wesley vai me matar porque ele adora gol também, mas poxa se eu tenho que subir um time com 100 pessoas pra codar gol, não tá tão fácil achar gente que coda gol no mercado, eu tenho que pensar nisso também, não é só chegar e sair codando uma nova plataforma inteira em gol e depois eu vou ter que formar 500 pessoas. Eu preciso pensar nisso também. E aqui foi só um exemplo, tá? Deve ter vários outros que a gente tem que ir pensando ali no dia a dia. Não vou falar de dotnet core, porque senão vai ter gente que vai me matar, tá? Não vou trazer isso pra mesa hoje não. Acho que hoje não é o dia da briga.