E se esta fosse a última migração da sua aplicação?

Modernizar ou desenvolver de novo? Há muito que deixei de ver duas disciplinas.

O meu primeiro projecto de reengenharia de sistemas de informação foi em 1997, na extinta Portugal Telecom. Já na altura se pretendia que a reengenharia seguisse, tanto quanto possível, o mesmo processo da engenharia de software.

Hoje chamamos modernização aplicacional à reengenharia de sistemas de informação. Para muitos, a modernização é apenas tecnológica. Para mim é também funcional, não só porque uma parte significativa das aplicações legadas já não é usada, mas também porque se as legadas não evoluírem funcionalmente, as necessidades de negócio levam ao aparecimento de novas aplicações, aumentando a complexidade do portefólio aplicacional.

Como sabemos, até hoje tem sido mais fácil fazer de novo do que evoluir o legado.

Quase trinta anos depois, mantenho a mesma visão: modernizar uma aplicação legada e construir uma aplicação nova são o mesmo processo de engenharia. Diferem em dois momentos apenas. Tudo o resto é um tronco comum.

A principal diferença é de onde vêm os requisitos

Qualquer aplicação nasce de requisitos. A questão é a origem deles.

No desenvolvimento clássico, os requisitos são “levantados” por diversas abordagens: workshops com o negócio, desenho de processos, entre outras.

Na modernização, os requisitos são “recuperados”.

Defendo que a abordagem que potencia uma maior modernização funcional é a gravação das jornadas de utilização da aplicação. Processadas por técnicas de process mining, estas jornadas deixam claro não só as interações individuais mas também como estas, coletivamente, produzem o propósito de negócio.

O cruzamento com a análise do código-fonte e da documentação obsoleta existente, usada sobretudo para apanhar o vocabulário do negócio, permite recuperar os requisitos e o propósito da aplicação.

E é aqui que acontece a limpeza que nenhuma conversão code-to-code faz: entre código morto, funcionalidades que ninguém usa há anos e funcionalidades duplicadas entre aplicações, 40 a 50% do código legado não precisa de ser migrado.

Recuperar requisitos é também decidir, com o negócio, o que deve ser migrado.

No fundo, o levantamento e a recuperação são técnicas diferentes para responder à mesma pergunta:

O que deve esta aplicação fazer?

Mas a partir do momento em que a resposta existe, os dois caminhos convergem.

Ambas as técnicas são extensivamente suportadas por agentes, embora a recuperação seja praticamente impossível de fazer manualmente.

O tronco comum

Daí para a frente, o processo não sabe, nem precisa de saber, se um requisito nasceu num workshop ou foi extraído de um sistema com vinte anos. Têm a mesma forma e são medidos pelos mesmos critérios de qualidade.

Segue-se o desenho funcional e técnico.

Hoje todo este desenho funcional e técnico é feito por agentes sob supervisão humana, com uma arquitectura de referência em cada etapa. Os agentes não inventam. Seguem padrões e regras bem claras.

Os testes derivam da especificação, com regressão completa desde o primeiro dia e cada linha de código rastreada ao requisito que a justifica.

Quem, como eu, vem das velhas engenharias conhece todo este processo.

A grande diferença é que, apesar de os artefactos de desenho serem os mesmos de sempre, agora deixaram de ser passivos e passaram a ser acionáveis.

Antes, um artefacto de desenho servia para alguém o ler e produzir o artefacto seguinte; hoje, serve para gerar o artefacto seguinte, e é aqui que está a essência da automatização do desenho funcional e técnico, que sustenta o spec-driven development por agentes.

Isto é a engenharia de sempre, mas agora automatizável do princípio ao fim e aplicável tanto às aplicações desenvolvidas de raiz como às “modernizadas”.

A geração de código por agentes a partir de “specs” é hoje uma trivialidade.

O segundo momento de diferença: a prova final

Antes de entrar em produção, é preciso assegurar o correto funcionamento da aplicação.

Numa aplicação nova, a fonte de verdade são os requisitos validados e a prova de fogo são os testes deles derivados.

Os testes contra os requisitos são também aplicáveis às aplicações modernizadas. Mas para as funcionalidades que não foram alteradas na modernização podemos ainda considerar a validação por comparação dos resultados da execução paralela entre a nova aplicação e a legada.

Esta técnica é normalmente bastante complexa. Mas ao gerarmos o código podemos incluir desde logo todo o aparato necessário para facilitar a execução em paralelo das aplicações, viabilizando esta técnica em muitas situações em que, de outra forma, não seria possível.

A grande vantagem é que o cliente não tem que fazer testes de aceitação.

A aplicação legada só se desliga quando a nova provou, de forma sustentada, comportamento idêntico.

Depois do go-live, os caminhos tornam-se indistinguíveis

E é aqui que o ciclo se fecha.

Uma aplicação modernizada por esta via é mantida exatamente como uma aplicação desenvolvida de raiz: alterar a aplicação é alterar um requisito e regenerar código e testes, com documentação sempre atualizada como subproduto.

Não existe um segundo regime de manutenção, mais caro e mais frágil, para as aplicações migradas, o destino habitual das conversões code-to-code, que deixam código novo, totalmente desconhecido e normalmente seguindo padrões e princípios que não são os da organização.

Há uma consequência que considero a mais importante de todas:

Esta será a última migração.

Sabemos que tanto o código como os requisitos ficam obsoletos, mas os requisitos são muito mais fáceis de modernizar que o código.

Uma vez atualizados os requisitos, só temos que gerar novamente o código, algo que é cada vez mais trivial.

Os requisitos, até agora normalmente deixados ao abandono, são hoje o verdadeiro asset estratégico do portefólio aplicacional.

Pedro Sousa
Application Modernization
Link Consulting