As empresas estão em constante evolução e as aplicações existentes precisam evoluir para atender aos requisitos de negócios.

Os clientes estão cada vez mais exigentes. Para atender a essa demanda requer que a empresa reaja rapidamente a suas necessidades. E tecnologia é imprescindível para responder a essa demanda.

O problema é que os sistemas se tornam legados com o passar do tempo, passam a ser "resistentes à mudança" e evolução.

Mas antes de seguir em frente, veja estes dois artigos sobre Por que migrar uma aplicação? e Quando migrar o legado?.

Partindo do principio que esta decisão já foi tomada, este artigo aborda estratégias sobre como migrar.

Entendendo a evolução

Evolução de sistema pode ser divididas em três categorias: manutenção, modernização e substituição.

  • Manutenção - É um processo incremental de pequenas mudanças. Geralmente são correções de bugs ou pequenas features. Não envolvem grandes alterações estruturais.
  • Modernização - Envolve mudanças mais extensas do que a manutenção, mas conserva uma parte significativa do sistema existente. Essas alterações podem incluir a reestruturação do sistema ou o aprimoramento da funcionalidade.
  • Substituição - Requer a reconstrução do sistema a partir do zero.

Modernização se refere a mudanças em grande escala. O objetivo é prolongar a vida útil do software.

Atualmente estratégias mais adotas são modernização e manutenção. A substituição do software é um risco muito alto. Significa recomeçar do zero. Um software totalmente novo. E é um tipo de risco que, por mais, que justifique, as empresas buscam o caminho da modernização.

Estratégias para modernizar

Várias estratégias de modernização existem hoje no mercado. Muitas empresas vêm consolidando a infraestrutura, migrando para a Cloud, adotando Microsserviços e APIs. Utilizando metodologias ágeis, DevOps e adotando estratégias incrementais para modernizar seus sistemas legados.

É necessário uma avaliação cuidadosa para identificar a estratégia mais adequada. Entender se esta estratégia é possivel de ser adotada dentro da empresa, se há match cultural entre a abordagem e os processos internos.

A nova solução proposta deve abordar os desafios do legado, estar alinhada com o budget. Uma boa estratégia envolve mais de uma abordagem. Por exemplo, se o gatilho para mudança é redução de custo da perspectiva da TI, é razoável sugerir uma hospedagem na nuvem (Re-hosting), porém pode incorrer problemas de segurança. Que resulta na reestruturação completa do sistema (Re-architecting).

Para desenvolver uma estratégia de modernização, os profissionais envolvidos devem ter clara compreensão das opções de modernização disponíveis.

Ao determinar as estratégias, é importante considerar algumas suposições e perguntas básicas. As perguntas a seguir fornecem uma diretriz inicial para a seleção de estratégias necessárias para a modernização:

  • Algumas funcionalidades podem ser substituidas por um produto comercial?
    • Uma tela de dashboard com KPIs poderia ser transferido para o Klipfólio (Ferramenta de dashboard realtime)
  • Quais são as features e regras de negócios do aplicativo atual?
  • Como os dados são acessados e usados?
  • Quantas integrações existem? Elas serão impactadas?
  • Há produtos/componentes externos sendo utilizados? Precisarão ser substituidos?
  • Como o novo aplicativo será testado?
  • Transformar o aplicativo em Microsserviços, quais são as implicações de segurança?
  • Quanto vai custar a modernização? Há budget suficiente?

Leve em consideração utilizar tecnologias open source na estratégia de modernização. Elas oferecem elementos fundamentais e essenciais para uma plataforma flexível e escalável.

Ao projetar a arquitetura considere em ir para a nuvem, utilizar conteiners, orquestração de contêineres, OpenApi, mensageria, um gateway API.

Entenda o tipo do dado. Se é melhor armazer em um banco relacional ou em um NoSQL.

I’ve got a special place for cool coffee shop menus…

6 R's da Modernização

opcoes-modernizacao

As seguintes estratégias de modernização estão disponíveis para lidar com os desafios do sistema legado. Mais de uma estratégia pode ser aplicado em uma modernização.

Cada estratégia tem cenários e motivadores exclusivos. A seguir cada uma da definições e onde cada abordagem pode ser usada.

6rs

Retain

Significa rever no futuro, pois não será feito nada agora. Você deve migrar apenas o que faz sentido para a empresa. E as vezes, não fazer nada é a melhor opção. Conforme descrevi em outro artigo, motivos para Quando não modernizar.

Retire

Aposentar envolve desligar aplicativos obsoletos. Isso inclui remover o aplicativo da produção. Porém mantendo o acesso aos dados históricos. Um item crítico a ser considerado é como os dados podem ser recuperados posteriormente. Isso geralmente envolve a migração dos dados para outro repositório. O retire também significa encerrar um sistema legado que foi modernizado.

Segundo analistas da Amazon, cerca de 10% dos sistemas em produção nas empresas não é mais útil e pode simplesmente ser desligado.

Rehost

Também conhecido como "lift-and-shift". Envolve mover o sistema existente para uma plataforma diferente. Por exemplo, a nuvem.

Os benefícios estão nos custos. Seja hardware ou licensiamento de software. Indo para nuvem estes custos podem diminuir significativamente. Rehost também pode envolver a mudança de um mainframe para um ambiente de custo mais baixo.

Os principais gatilhos para esta estratégia são infraestrutura legada, custos operacionais e de licença.

Replataform

O foco é mudar o minimo possivel do código e da lógica para obter benefícios significativos trocando de plataforma. Por exemplo transformar uma aplicação Web em uma PWA. Sem grandes alterações estruturais da aplicação. Pode alterar para utilizar recursos de nuvem, como um Blob para armazenar imagens ou um database as a service como o Azure SQL.

Refactor / Rearchitecture

Re-arquitetar a aplicação para uma estrutura moderna. Mantendo as regras de negócios existente.
Envolve a engenharia reversa do aplicativo. Para entender os requisitos e ter bases para projetar essas regras de negócios para um novo ambiente. Com base em uma arquitetura moderna.

Nessa migração deve considerar as boas práticas modernas de desenvolvimento, amplamente debatida na comunidade. Conteiners, implementar APIs e Microsserviços. Aproveitar abordagens de DevOps ou DevSecOps.

Essa abordagem geralmente é a mais cara. Geralmente quando se toma essa decisão é porque o legado deixou de entregar agilidade ou performance. Tornande-se caro demais para manter e com riscos para a operação.

Replace / Repurchasing

O aplicativo legado pode ser substituído por uma solução totalmente nova e disponivel no mercado. Haverá o benefício de receber suporte do fornecedor.

Construir um novo sistema é muitas vezes caro, lento e arriscado. E utilizar uma solução consolidada de mercado diminui esse risco além de entregar resultado mais rápido.

Dependendo da literatura outras estratégias podem aparecer. Resolvi colocar os 6 R's por entender que estas são as mais utilizadas atualmente.

Conclusão

É essencial fazer uma avaliação antes de migrar um sistema legado. Determinar qual é a(s) melhor(es) estratégia(s), sempre alinhado com o objetivo do negócio.

Espero que esse artigo ajude vocês a decidirem um caminho menos ardiloso. E que tenha aberto a sua mente e que você ajude seu time a tomar melhores decisões.

Referências