Primeiras aulas do curso
Olá, turma.
Estamos iniciando um novo módulo da nossa trilha de arquitetura de soluções. Vamos falar sobre modernização de sistemas legados e evolução arquitetural.
Esse tema é fundamental para o bom exercício do papel e das responsabilidades de uma pessoa arquiteta de soluções. Nós vamos tratar de como modernizar um sistema legado, e cabe à pessoa arquiteta direcionar como realizar essa migração.
Uma aplicação legada não se refere apenas à tecnologia, a uma linguagem em desuso ou à simples modernização de um servidor ou forma de execução; trata-se também do negócio. Modernizar uma aplicação é atender às necessidades do negócio e, do ponto de vista da evolução arquitetural, garantir que essa aplicação esteja preparada para acompanhar a evolução do negócio.
Portanto, migrar um sistema legado não significa que a aplicação nova não possa, em breve, se tornar um sistema legado, caso não tomemos alguns cuidados. Vamos entender melhor esses pontos.
Vamos discutir os frameworks (arcabouços) do mercado que nos apoiam, como pessoas arquitetas, a realizar a migração e o uso de inteligência artificial e de agentes para ler e entender o que o código legado pretendia implementar e nos informar. Muitos desses sistemas legados não possuem documentação, portanto é muito útil utilizar agentes.
Abordaremos a camada anticorrupção e a migração por domínios. É importante que a pessoa arquiteta compreenda e apoie o negócio na definição do recorte correto do domínio a ser migrado. Essa é uma estratégia muito útil atualmente. Também discutiremos decisões que podemos tomar e que são irreversíveis, o que exige uma boa estratégia de migração.
Antes de começarmos, eu sou Eder Thuller.
Audiodescrição: Eder é uma pessoa branca, de 49 anos, com olhos claros, usando óculos de moldura azul, cabelo castanho penteado de lado, barba curta e camisa polo preta.
Depois dessa autodescrição, no próximo encontro começaremos a falar sobre o nosso tema. Conto com vocês, até lá.
Muito bem, turma. Dando prosseguimento na cadeira de arquitetura de solução, vamos falar sobre modernização de sistemas legados e evolução arquitetural.
Esse tema é recorrente no nosso dia a dia no mercado: modernizar aplicações, sistemas e evoluir a arquitetura.
Vamos começar afirmando que todo sistema tende a “morrer”, isto é, a ser desativado em algum momento. Em outras palavras, todo sistema quer “morrer”.
Pode parecer uma afirmação dura para o início do curso, mas utilizaremos uma analogia com a vida humana: nascimento, crescimento, amadurecimento, envelhecimento e, por fim, a morte. Da mesma forma, isso ocorre com as aplicações.
Nós desenvolvemos aplicações que, em geral, já têm uma data de desligamento, ainda que não saibamos qual é. Mas quem define isso? Como isso é possível?
Retomando um conceito das aulas de física, pela segunda lei da termodinâmica, todo sistema fechado tende ao caos. Ele nasce organizado e tende ao caos. Isso não é específico da tecnologia, é um princípio da física. Por exemplo: se deixarmos uma xícara de café quente parada, sem fogo e sem nenhuma ação para mantê-la quente, ela esfria. Um quarto arrumado se desorganiza. Uma casa sem manutenção se deteriora. Experimentamos isso no dia a dia: se deixarmos um carro novo parado na rua, na garagem ou em qualquer lugar por um ano, não o encontraremos melhor do que deixamos; ele estará pior. O mesmo ocorre com um tênis recém-comprado: com o uso e o passar do tempo, ele não melhora; envelhece, desorganiza-se e estraga. Assim também acontece com nossos sistemas. Não é um acidente; é física, a segunda lei da termodinâmica.
A única forma de reverter essa tendência é gastar energia. Se o carro está com pneu vazio, empoeirado, com peças ressecadas pelo sol ou pela chuva, precisamos investir energia: encher ou trocar os pneus, aplicar produtos, lavar o carro. O mesmo vale para o tênis, para a casa, para o quarto. Isso também acontece com as aplicações.
Avançando, essa mesma lei se manifesta no código. As Leis de Lehman sobre evolução do software (programa) trazem princípios que se aplicam ao entendimento de sistemas e aplicações. Os sistemas exigem esforço, energia, para se manterem funcionais, operando e atendendo ao seu propósito. Se não investirmos energia, serão, em breve, desligados.
Em 1974, Meir Lehman estudou a evolução de um sistema da IBM e concluiu: o software (programa) obedece a um princípio análogo ao da termodinâmica; a entropia de um sistema aumenta com o tempo, a menos que trabalho específico seja executado para mantê-la ou reduzi-la. Com o tempo de evolução e uso de um software (programa), surgem dependências que não deveriam existir. Quantas vezes dizemos ou ouvimos: “Vamos fazer desse jeito e depois corrigimos”? Isso aumenta a entropia dos sistemas. Correções, exceções, diversas features (funcionalidades), prazos apertados — quantos de nós trabalhamos assim? Frequentemente precisamos executar tarefas para as quais gostaríamos de ter mais tempo para pensar e projetar, mas precisamos entregar. Isso eleva a entropia do software (programa).
Portanto, na maioria das vezes, não se trata de “enrolação” do time; é física. Em projetos com cronogramas rígidos, quando ouvimos “tem que fazer no prazo”, “faça desse jeito e depois consertamos”, “depois expomos isso com um contrato melhor”, “depois fazemos uma query (consulta) mais eficiente”, a tendência é que esses itens se acumulem e não sejam resolvidos. A entropia do software (programa) aumenta.
Vamos desfazer o mito de que “sistema antigo” é, necessariamente, sistema legado. Segundo o Michael, “código legado é simplesmente código sem testes”.
Vejamos dois exemplos:
15 anos de idade: temos uma aplicação, um software (programa), um sistema com 15 anos. Há testes robustos, fronteiras de domínio claras, documentação viva. O software (programa) atende ao negócio e recebe energia (investimento e manutenção). Não há prazos constantemente apertados nem a dinâmica de “lançar e depois corrigir”. O time é coeso. Apesar de ter 15 anos, esse sistema não é legado.
8 meses de idade: um software (programa) lançado sob pressão, com MVPs (produtos mínimos viáveis) eternos, “teste em produção”, atalhos acumulados e inúmeros “depois eu conserto; vamos lançar e depois conserto”. É muito provável que esse software (programa) já tenha data marcada para ser desligado, tornando-se legado.
Portanto, não se trata da data de criação do software (programa). Não é porque um sistema tem 20, 25, 10 ou 15 anos que é legado. Não é o fato de estar em COBOL ou C que o torna legado. A questão é a capacidade do sistema de mudar com segurança: se é código sem testes, repleto de adaptações improvisadas e complexo de alterar, então é legado, como propõe o Michael.
Vamos manter essa referência para retomá-la adiante.
Outro ponto importante na modernização de sistemas legados e em arquitetura é não supor que conseguiremos construir uma arquitetura que não se deteriore.
Vamos confessar que, às vezes, pensávamos que iríamos modelar e propor uma arquitetura que seria eterna. Isso não acontece. Se ela não receber trabalho constante, observação contínua e direcionamento recorrente, estará fadada a morrer.
Vamos estudar técnicas para manter a arquitetura viva, realizar modernizações e aplicar energia para evitar que as leis da física atuem sobre a aplicação. O sistema novo e brilhante, com ou sem IA, que vamos construir ou acabamos de construir, também está sujeito à segunda lei da termodinâmica. Não existe uma arquitetura ou solução imune à entropia.
A pergunta que fica é: que trabalho estamos investindo continuamente para desacelerar a entropia do sistema que estamos construindo? O trabalho de arquitetura, junto com os times de desenvolvimento e de produto, deve responder a isso. Qual energia estamos colocando? A cada entrega, estamos entregando algo que desacelera a entropia ou algo que a aumenta? Em outras palavras, estamos aumentando o caos ou diminuindo o caos? Estamos organizando ou desorganizando o sistema?
Nem sempre vamos entregar algo que organize. Isso também é um fato. Não devemos criar a expectativa de que só entregaremos melhorias. Temos o time do projeto, a necessidade do negócio, prazos e metas a serem cumpridas. Na maior parte do tempo, podemos acabar entregando algo que gera mais caos — é a física atuando. Ainda assim, precisamos buscar sempre entregar um trabalho que também organize, que traga energia para enfraquecer ou retardar a entropia do sistema e da aplicação.
A primeira lei de Lehman diz o seguinte: sistemas do tipo E devem ser continuamente adaptados ou se tornam progressivamente menos satisfatórios em uso. Aqui estamos falando sobre evolução de software. Lehman estabeleceu, em sua publicação sobre evolução de software, algumas leis, e a primeira afirma que sistemas do tipo E precisam de adaptação contínua. Sabemos disso: ao criar um sistema e colocá-lo em produção, com o tempo, precisamos continuar adaptando e melhorando. Se não fizermos isso, ele se tornará menos satisfatório.
Trabalhamos há algum tempo com uma pessoa desenvolvedora que costumava entregar uma solução, e costumávamos dizer: “ficou bom”. A resposta recorrente era: “está bom, mas sempre pode melhorar”. E, de fato, precisamos sempre melhorar a aplicação.
Essa é a primeira lei de Lehman. Mas o que é um sistema do tipo E? Estamos falando, basicamente, das aplicações que usamos no dia a dia, classificadas como tipo E de Embedded (embutido), isto é, qualquer sistema inserido no mundo real, cujo domínio do problema muda com o tempo. Em outras palavras, tudo que usamos hoje no mercado, como:
Essas aplicações, classificadas como tipo E, precisam ser adaptadas porque o negócio muda. Se recuperarmos uma aplicação de 15 ou 20 anos atrás, talvez não tivéssemos algumas agências reguladoras para as quais precisamos enviar informação hoje. Concorrentes, integrações e parcerias mudam o negócio continuamente. Surgem novas formas de pagamento. Antes do Pix, no setor bancário, havia DOC e TED como formas amplamente utilizadas de transferência de valores; hoje, praticamente tudo se resolve com Pix. Antes havia apenas cartões de crédito; agora há também cartões de alimentação e de refeição. O sistema precisa acompanhar o que surge de novidade.
Por definição, sem energia de manutenção, o sistema vai piorando e ficando menos satisfatório, às vezes mais lento. Ao fazer o primeiro deploy (implantação) de uma aplicação, o banco de dados está vazio, a mensageria está vazia, não há arquivos de log (registro), os filesystems (sistemas de arquivos) estão zerados, e a aplicação roda com determinada performance. Com o passar do tempo, as tabelas crescem, e precisamos colocar energia para mitigar esses efeitos e evitar que o software fique lento. É nesse sistema que precisamos, o tempo todo, colocar energia.
A definição de Michael afirma que um sistema sem testes é um sistema legado — aquele no qual não fazemos testes. Lehman complementa ao dizer que um sistema que não atende mais ao negócio ou apresenta dificuldade de incorporar as inovações exigidas também é um sistema legado. Podemos combinar essas duas definições: quando não conseguimos mais testar o sistema de ponta a ponta, ou quando não conseguimos mais evoluir as inovações (ou isso se torna muito complexo), ele tende a se tornar um sistema legado.
Avançando sobre duas leis principais de Lehman:
Considere um cenário de arquitetura corporativa no qual estamos organizando o catálogo de aplicações e montando uma visão de APM (gerenciamento de portfólio de aplicações). Precisamos classificar uma aplicação: está boa, mediana ou em descontinuação? Podemos aplicar essas duas leis para entender a situação da aplicação. Se ela está muito complexa para mudar, as releases (versões) demoram, os custos de desenvolvimento são altos e são necessárias muitas horas de trabalho para entregar uma funcionalidade. Ou, então, ela não consegue acompanhar o negócio, que está sempre reclamando dos prazos porque tudo demora.
Essa análise leva à classificação de que o sistema já apresenta falha de adaptação.
Outro sintoma do sistema é que, a cada mudança, alteramos uma coisa e três outras quebram.
Já vimos isso diversas vezes; temos certeza de que você já passou por essa situação.
Realiza-se uma alteração e, de repente, o sistema falha em uma parte que não modificamos, que não deveria ter sido afetada, e, ainda assim, quebra.
Levamos semanas para entregar por causa de dependências que não deveriam existir, débito acumulado — ou, melhor, dívida acumulada —, uma arquitetura rígida, fronteiras definidas de forma equivocada e monólitos sem separação por domínio.
Ao observarmos diversas situações, podemos classificar se esse sistema está mais sujeito à entropia, à falha de adaptação ou, eventualmente, aos dois cenários.
Ele é complexo demais para atender ao negócio e não consegue mais evoluir em função dessa complexidade, dada a entropia.
O sistema nasceu organizado e, agora, tornou-se um caos devido à quantidade de elementos que fomos adicionando.
Diante disso, deixamos um ponto de atenção ao final deste módulo.
Nem todo sistema que não atende ao negócio é, tecnicamente, um legado.
Ele pode ser impecável, pode estar bem testado, bem modularizado, com baixa entropia — ou seja, não está em desordem — e, mesmo assim, não atender ao negócio.
Isso ocorre porque o negócio mudou.
Nessa situação, não adianta reescrevê-lo; não se trata apenas de modernização, e sim de uma mudança no negócio.
Podemos ter baixa entropia técnica, testes adequados, modularização e fronteiras bem definidas, sem débito técnico. Entretanto, o domínio mudou, o negócio mudou — não apenas a implementação.
Um exemplo é o das antigas aplicações de locação de DVD e fitas. Funcionavam bem: banco de dados bem tratado, índices, tabelas, tudo em ordem, leitor de código de barras. No entanto, esse modelo de negócio deixou de existir; agora é streaming (transmissão).
Esse sistema não será modernizado; será substituído por um novo, porque o negócio mudou.
Quando o domínio muda, não existe mais modernização. Nesse caso, nós realmente precisamos criar um novo sistema para atender ao novo domínio e às novas regras de negócio.
É importante entender isso, pois, em muitas situações, podemos ser levados a dizer: “vamos modernizar”.
Ao olhar para o negócio para avaliar a modernização, abrimos um parênteses: modernizar não pode ser apenas tech (tecnologia) por tech (tecnologia).
“Vamos modernizar, tirar da linguagem tal e colocar na linguagem Y.” “Vamos sair de COBOL e ir para Python.”
Apenas tecnologia pela tecnologia não basta. É necessário considerar o negócio e compreender a modernização sob essa perspectiva. Em alguns casos, não é modernizar; é criar uma nova aplicação.
Vale a pena discutirmos mais sobre isso na próxima aula, mas já deixamos registrado aqui.
O que é um sistema legado?
É quando a distância entre o que ele faz e o que o negócio precisa está aumentando.
O sistema se torna legado quando há uma necessidade de negócio e, cada vez mais, nossa aplicação se distancia da capacidade de atendê-la.
Ou seja, quando acumulamos tantas dívidas técnicas que não conseguimos pagá-las, e as necessidades do negócio se tornam cada vez mais difíceis de atender, o sistema caminha para o legado.
Na prática, as duas leis de Lima, tanto a de entropia quanto a de adaptação do sistema, normalmente atuam juntas.
Mais complexidade gera mais caos, o que torna a adaptação mais difícil.
Esse ciclo se reforça até que percebemos que o sistema está em descontinuação: precisa ser substituído ou modernizado, pois não atende mais ao negócio.
A partir daí, nós efetivamente iniciamos o trabalho de modernização.
Vamos encerrar por aqui.
Em breve, vamos começar o próximo módulo.
Um abraço!
Muito bem, turma.
Vamos dar continuidade na disciplina de arquitetura, na trilha de arquitetura de solução e na modernização de legados. Vamos focar no diagnóstico das aplicações legadas.
Como entendemos que uma aplicação, de fato, é legada, ou que está candidata a se tornar legada, mesmo quando eventualmente ainda não é? Isso vale mesmo quando não apreciamos a aplicação, a linguagem ou a forma como foi escrita. Nosso objetivo é entender, gerar dados e fatos e, com isso, produzir um diagnóstico correto, para que a diretoria compreenda quando uma aplicação é, de fato, um legado.
O diagnóstico ingênuo é a principal causa de investimentos equivocados. Talvez estejamos focados em modernização, em trocar uma aplicação por um software de prateleira ou em alocar um time para melhorar aquela aplicação, quando, na verdade, ela pode não ser o problema da nossa esteira ou do nosso ecossistema. O ideal é passarmos por etapas que nos permitam chegar a um diagnóstico consistente. Pensar em modernizar sem diagnosticar é como operar sem realizar um exame prévio. Muitas pessoas chamam esse processo de um assessment (avaliação diagnóstica) do ecossistema.
Alguns pontos precisam ser entendidos. Nossa arquitetura real sempre diverge do design (projeto) original. Uma aplicação, na sua concepção, tem um desenho; com o passar do tempo, a arquitetura em produção tende a se afastar daquele desenho. Precisamos, às vezes, recorrer à engenharia reversa, olhar o código e entender como ele se modificou ao longo do tempo. Somente um diagnóstico cuidadoso revela essa divergência, evitando que tratemos o ponto errado. É necessário conhecer e mergulhar na arquitetura e na aplicação em produção para compreender o que precisa ser modernizado.
Esse diagnóstico ocorre em três camadas: código, processo organizacional e impacto no negócio. Como citamos na aula anterior, muitas vezes pensamos em modernizar apenas o código. Queremos sair de COBOL ou C++ e ir para Python. Buscamos uma linguagem mais atual simplesmente trocando o código. Porém, isso é apenas uma das etapas. Precisamos avaliar o processo organizacional e o impacto no negócio. O enfoque de tech for tech (tecnologia pela tecnologia) — modernizar código sem olhar processo e negócio — tende a produzir um diagnóstico ingênuo e um trabalho mal elaborado. Precisamos considerar os três pontos.
Diagnosticamos uma aplicação como legada quando observamos o desequilíbrio entre a necessidade de contrair dívidas técnicas e a capacidade de pagá-las. Muitas dívidas foram contraídas no passado por questões de prazo — era um MVP (Produto Mínimo Viável) que precisávamos lançar — e, considerando a entropia, a tendência é que o sistema se desorganize. A cada trecho de código incluído e a cada release (lançamento) publicado sob pressão, aumenta-se a desorganização da aplicação. Chamamos isso de dívida técnica. Quando precisamos contrair muitas dívidas e não conseguimos pagá-las, esse desbalanceamento — tal qual um balanço financeiro em que há mais necessidade de nova dívida e menor capacidade de pagamento — é um grande indicador de que a aplicação está caminhando para uma indicação de legado e precisa ser modernizada.
Esse diagnóstico precisa ser contínuo. Tiramos uma “foto” hoje, por exemplo, no contexto de arquitetura corporativa, observando via um APM (monitoramento de desempenho de aplicações) e classificando o software pela linguagem, pelo atendimento ao negócio e pelas dívidas técnicas. Em organizações mais evoluídas, existe um catálogo no qual registramos quantas dívidas um software possui, qual é a linguagem, se essa linguagem ainda é amplamente utilizada, entre outros critérios. Classificando o software, obtemos um diagnóstico sólido para entender se ele está pronto para ser modernizado ou se ainda é uma aplicação robusta, apesar do tempo de vida e da linguagem utilizada. Esse olhar da arquitetura sobre o software deve ser contínuo, seja ele legado ou não. Para conter a entropia, precisamos aplicar uma força contrária que a reduza. Assim, mantemos o software saudável sem grandes esforços.
Para um bom diagnóstico, medimos duas dimensões da dívida técnica: a capacidade de pagamento e a necessidade de contrair novas dívidas. Como realizamos essa medição?
Quanto tempo o time tem disponível para refatoração e manutenção estrutural? Temos metas de atendimento, diversas squads (equipes) trabalhando e várias features (funcionalidades) a implementar. O time está ativo, mas quanto tempo possui para a sustentação? Quanto tempo do nosso baseline (linha de base) é reservado para isso? Por exemplo, se o time tem capacidade de 200 horas por mês, quantas dessas horas estamos separando para pagar dívidas, refatorar e realizar manutenção estrutural da arquitetura, dos componentes e da solução? Se uma squad (equipe) com 200 horas mensais usa as 200 horas apenas para novidades, não há tempo para pagar dívidas.
O time tem conhecimento suficiente para pagar a dívida com segurança? É um time robusto, sênior? Temos pessoas com capacidade de pagar essas dívidas sem contrair novas? Isso é fundamental. Às vezes pagamos uma dívida e contraímos duas, como quando pagamos um empréstimo contraindo outro com juros maiores, resultando em um passivo maior do que antes.
Existem testes que permitam refatorar com segurança? Ou é aquela aplicação ou módulo “intocável”, no qual ouvimos: “Não mexa nisso, porque deu problema; na última vez que alteramos, ficamos fora do ar e foi um caos.” Se isso ocorre, a capacidade de pagar essa dívida está fortemente reduzida.
Por outro lado, o negócio pode estar pedindo mudanças que não cabem na arquitetura atual: integrações com parceiros, consumo direto das nossas APIs (interfaces de programação de aplicações), e não temos essas APIs expostas ou não as modelamos de maneira adequada. Sob pressão para entregar, surgem atalhos, como criar uma tabela para contornar rapidamente a necessidade. Esses sinais reforçam o descompasso entre as demandas do negócio e a capacidade técnica da arquitetura atual, exigindo um diagnóstico criterioso e ações de modernização bem planejadas.
Se isso aconteceu com você, é porque está, de fato, no dia a dia das empresas; é assim que tem funcionado.
Se nessas duas dimensões a capacidade de pagar a dívida técnica é muito baixa, enquanto a necessidade de contrair nova dívida cresce cada vez mais, temos um diagnóstico quase certeiro de que essa aplicação está na trajetória de se tornar um legado. Mesmo que hoje esteja em execução e atendendo, é forte candidata a se tornar um legado.
As duas Leis de Lima tratam disso. A primeira, relacionada à capacidade de adaptação, descreve o tipo E. Na aula passada, trabalhamos com o Embed (incorporado), que significa o sistema que atende ao negócio, ao nosso dia a dia. Se ele se torna difícil de adaptar, já estamos diante de um passo em direção a uma aplicação legada.
Se a entropia interna aumenta — ou seja, à medida que o sistema evolui, a complexidade cresce e isso gera mais dívida, acarretando, como em nossa vida, mais impostos —, esse também é um forte indício de um sistema legado.
Muitas vezes temos uma solução muito interessante, bastante aderente às novas práticas, mas que aumenta demais a complexidade do sistema. Embora caminhemos para melhorar a adaptação, adquirimos complexidade. Assim, buscamos atender à primeira lei (capacidade de adaptação), mas, ao mesmo tempo, geramos complexidade e trazemos mais entropia para a aplicação. Essas forças podem atuar juntas, uma provocando a outra. É importante observar isso no nosso dia a dia e nas nossas aplicações.
Complexidade é qualquer característica relacionada à estrutura de um sistema de software que dificulta entendê-lo e modificá-lo. Muitas vezes queremos criar um código excelente, um algoritmo muito pragmático, mas que introduz grande complexidade. Torna-se difícil de entender e de manter por outras pessoas. Se inserimos isso na aplicação, aumentamos a complexidade e a entropia, o que significa que o sistema está se tornando mais caótico.
Entropia multiplicada pela capacidade de adaptação. Se, nessa matriz, considerarmos baixa e alta entropia, assim como alta e baixa adaptação, temos um mapeamento para a primeira e a segunda leis.
Baixa entropia e alta adaptação: o sistema não é complexo, é fácil de modificar, não há receio de quebrar outros módulos, executamos testes com segurança e ele atende ao negócio, gerando valor de forma saudável. Não há ação a ser tomada nem necessidade de mudança. Ainda que tenha sido desenvolvido em COBOL, Clipper, Delphi ou C, ele é saudável. Não precisamos modernizar uma aplicação assim, a menos que, por exemplo, em COBOL, esteja rodando em um servidor exclusivo e com alto custo de manutenção — aí entramos em uma análise estratégica financeira. Do ponto de vista técnico e de arquitetura, ele está adequado.
Alta entropia e alta adaptação: o sistema ainda atende ao negócio, mas já apresenta complexidade relevante. Direcionar esforço para pagar algumas dívidas técnicas pode resolver; talvez não seja necessária uma modernização completa. Podemos concentrar energia nos pontos mais caóticos para organizar o que está bagunçado.
Baixa entropia e baixa adaptação: pela primeira lei, o sistema do tipo E se torna difícil de adaptar; ele não atende mais ao negócio, embora não seja complexo. Está obsoleto por domínio. Por exemplo, em um sistema de CRM no qual a comunicação com o cliente ocorre por múltiplos canais (WhatsApp, mensagens, e-mail), precisamos visualizar no CRM todos os canais que a pessoa cliente utiliza. Se a aplicação de CRM não possui funcionalidades para comunicação via WhatsApp, mensageria e e-mail, atendendo apenas por um único canal humano, ela não atende mais ao domínio. Nesse caso, talvez não baste modernizar; pode ser necessário substituir o próprio sistema.
Alta entropia e baixa adaptação: o sistema não se adapta e é muito complexo de modificar. É um legado crítico, candidato natural à modernização. Nesse ponto, aplicamos o framework (estrutura) do Strangler Fig (Figueira-estranguladora) — veremos isso na próxima aula — para apoiar a migração.
Essa matriz é importante no diagnóstico de sistemas legados.
O ciclo vicioso é mais perigoso. O caso mais comum na prática não é um sistema nascer no quadrante vermelho (o legado). Dificilmente ele nasce ali, mas migra para lá muito rápido. Esse é o problema: estamos com uma aplicação nova, porém ela já nasce com alta complexidade devido à pressão.
O que causa a incapacidade de adaptação? Quanto mais dependências indevidas se acumulam, mais caro fica adaptar. Cada adaptação forçada sobre essa complexidade cria ainda mais desordem. É um ciclo que se retroalimenta.
Muitas vezes o time de negócio não tem essa percepção. Às vezes, o time de desenvolvimento também não. É nossa responsabilidade, como arquitetura, observar esse tipo de situação. É comum que o time de desenvolvimento queira entregar e escrever código, e que o negócio deseje anunciar rapidamente uma nova funcionalidade — por exemplo, lançar um canal de WhatsApp. Quem deve olhar para o ciclo de vida da aplicação e para esse ciclo vicioso é a arquitetura. Precisamos indicar: estamos seguindo por este caminho, mas há uma dívida a ser paga; negócio, precisamos endereçar essa dívida; time de desenvolvimento, isto não está saudável. Nosso papel é trazer essa visão. Corremos o risco de atender à necessidade imediata, mas contribuir para que a aplicação se torne legado muito rapidamente.
Proposta de atividade prática: pense agora em um sistema que você conhece no seu trabalho. Faça o exercício de fechar os olhos e refletir sobre a aplicação em que você tem trabalhado hoje.
Independentemente de trabalharmos com CRM, desenvolvimento bancário ou outra indústria, vamos identificar a aplicação e a camada do sistema nas quais atuamos.
Vamos pensar em uma aplicação ou sistema, inclusive um projeto pessoal.
Primeiro, na primeira etapa (5 minutos), vamos analisar:
Segundo, vamos avaliar a complexidade nas últimas releases (versões):
Em seguida, avaliamos e preenchemos a matriz de entropia:
É interessante praticar para termos um diagnóstico correto sobre a aplicação que eventualmente estamos pensando em modernizar.
Até a próxima. Um grande abraço.
O curso Sistemas legados: modernização arquitetural orientada ao negócio possui 173 minutos de vídeos, em um total de 45 atividades. Gostou? Conheça nossos outros cursos de Arquitetura de Software em Back-end, ou leia nossos artigos de Back-end.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
Todos os cursos, trilhas e certificados para evoluir.
7 dias para cancelar com reembolso
Aprenda mais rápido com IA, idiomas e imersões.
7 dias para cancelar com reembolso
TUDO DO PLUS, MAIS:
Aceleração de carreira: mentoria, vagas e prática guiada.
7 dias para cancelar com reembolso
TUDO DO PRO, MAIS:
