Sem matar a piada, podemos afirmar com segurança, isso – semelhante a outras promessas de soluções complexas de processamento de informações, por exemplo, traduções automatizadas de idiomas – sempre esteve a apenas alguns anos de distância de nós.
O que é a BRE?
A extração de regras de negócios é um processo de análise de um pedaço de um aplicativo legado e de criação de uma descrição sobre ‘o que ele faz’. A parte ‘o quê’ inclui contexto, casos de uso, funcionalidade, dados sendo processados, interações, E/S, fórmulas computacionais, limites, restrições, etc. Tudo o que é necessário para poder reproduzir a funcionalidade exata em sua totalidade em um ambiente novo.
A saída de tal empreendimento pode ser em qualquer formato, geralmente são diagramas e inglês simples, o mais formal possível. Como se fosse um plano de sistema para começar.
Essas regras de negócios adquirem seu significado quando se tornam parte dos processos de negócios.
Por que e quando precisamos da BRE?
Durante a modernização do legado, projetos de transformação de aplicativos, se a decisão for refatorar/reescrever – em vez de ‘rehost’ – os aplicativos, os desenvolvedores e os analistas de negócios devem ter uma boa compreensão do que está acontecendo dentro do código.
Fundamentalmente, da perspectiva da BRE, um cliente pode ter duas abordagens posíveis para a modernização:
- ‘tocar’ no código e refatorar/reescrever que requererá a BRE, ou
- rehost/replatform, pegue o código legado e mova-lo para o mundo novo, de uma forma ou de outra.
Nós, o time da FreeSoft, garantimos o afastamento das linguagens e dos bancos de dados legados, o mais rápido possível. Uma vez no mundo novo, a disponibilidade do conhecimento, da tecnologia e das ferramentas é abundante, e o impacto da modernização é imediato.
Segundo a prioridade dos clientes, a BRE pode ser necessária. Claro, todos nós desejamos que isso seja simples, indolor, rápido e possivelmente automatizada. Oh, garoto!
Qual é o motivo?
Como já mencionei acima, a BRE é uma etapa útil caso o cliente decidir reescrever o aplicativo. Embora reescrever um aplicativo (quero dizer, centenas deles) seja um empreendimento demorado e arriscado, existem empresas com ‘poder de venda’ suficiente e cobram por T&M. No entanto, há uma razão legítima para a BRE: quando uma empresa decide usar um mecanismo de regras de negócios, como o PEGA.
Qual é a promessa?
Fique alarmado quando uma empresa promete ser capaz de fazer BRE automatizada e implementá-la nos mecanismos de regras de negócios. Deixe-me ser tão descarado quanto aqueles que afirmam que isso pode ser feito: isso é mentira total. Faça uma PoC com eles e vejam que eles não queriam dizer exatamente o que escreveram em suas páginas brancas. Eles precisam de certos artefatos, algumas PMEs para explicar e colocar os seus resultados em contexto ou provar que as regras extraídas são de fato significativas e utilizáveis por desenvolvedores e BAs. Entre em contato conosco e fala para nós se você está satisfeito. Conta-nos se essas empresas são capazes de escalar de algumas centenas de milhares de linhas de código para a magnitude de 10 milhões.
Pode ser automatizada?
A resposta curta é não. A resposta mais comprida seria – na verdade, não. Escanear e analisar o código pode ser feito e pode render alguns insights, mas sem a compreensão de uma ser humana nenhum significado pode ser dado aos resultados de tal análise. As principais armadilhas são:
- Nomeando objetos para a compreensão humana: vamos supor que o código está bem estruturado e os objetos são nomeados de forma congruente. Boa sorte com a atribuição de um nome significativo para “AUSATRN”, “C200-EVALUATE” e similares. E se os nomes não estiverem nem perto de serem legíveis e o fluxo de código for uma bagunça?..
- Uma análise estática de código é inerentemente incompleta porque o fluxo de código pode depender nos dados armazenados em algum lugar, acessíveis por meio de camadas de abstração (JCL, nomes lógicos).
- Uma regra de negócio não é um processo de negócio. Um processo pode envolver usuários de negócios para fazer isso, fazer aquilo: baixar/FTP um CSV, editá-lo (e às vezes quebrá-lo) de alguma forma, fazer upload de uma planilha do Excel etc.
- Corolário da anterior, correção: não podemos ter a certeza de que uma regra de negócio, mesmo extraída corretamente, é válida. Os usuários de negócios podem contornar algumas peculiaridades, regras de negócios codificadas incorretamente por anos. Nós já estivemos lá, nós já vimos isso!
- Um processo de BRE automatizada não substitui a documentação de um aplicativo… e a documentação é – para dizer o mínimo – um pouco ausente. Sinceramente, alguém se lembra por que o código foi alterado em 1993 por volta do Ano Novo por John? Foi uma correção de bug, acompanhando uma mudança na lei, um novo modelo de produto ou alguma especialidade com um distribuidor em algum lugar? Foi refletida essa mudança na documentação do sistema? Talvez. Mas apenas talvez. Mas mesmo se fosse, como seria posível uma BRE automatizada usar essa informação?
E a lista continua….
O que é que pode ser feito, então?
Não há substituto para a compreensão humana. Várias empresas e especialistas desenvolveram metodologias para a BRE, mas todas envolvem desenvolvedores, analistas de negócios, especialistas no assunto e usuários de negócios para obter uma boa ideia do que está acontecendo dentro do código legado e colocá-lo em um formato que possa ser usado. Esses processos levam tempo. Às vezes muito tempo, proporcional à quantidade de código. Devido à escassez de especialistas no assunto e desenvolvedores de linguagens legadas, o processo não pode realmente ser encurtado com o envolvimento de mais pessoas. Estamos a falando de anos aqui!
Então! O que é que um tomador de decisão razoável pode fazer em situações complexas como essas? Sugerimos uma abordagem de ‘dividir e conquistar’. Converta o legado para Java e faça a BRE apenas naquelas partes do sistema que exigem agilidade num futuro muito próximo.