Considerações sobre Workflows

O primeiro projeto em que participei no Serpro, assim que fui aprovado no concurso em 2006, era um super Workflow. Documentos que precisavam ser criados, revisados, aprovados, enviados para parecer e outras dezenas de situações. Fora as milhares de regras para definir quem vai executar uma determinada tarefa no documento. E o que dizer da quantidade de perfis e papeis? Era, e ainda é, pois ainda está em desenvolvimento, um mega sistema de Workflow. Até então, eu nunca havia sequer notado a existência de Workflows. E também já havia feito sistemas similares como, por exemplo, um sistema de comércio online e um sistema de notícias. Observando cuidadosamente, percebe-se que estes sistemas tem aspectos em comum: entidades que mudam de situação, pessoas que devem executar tarefas, e-mails que devem ser enviados, sistemas externos que devem ser acionados, etc.

A partir deste momento, fiquei de olhos mais atentos aos sistemas em que eu participava ou ajudava, sempre notando que muitos tinham características de Workflow, mas a equipe pouco percebia este detalhe importante. Para muitos, Workflow é algo mais relacionado aos negócios da empresa em que trabalha e a automatização destes negócios. Parece algo distante. Uma tecnologia meio alienígena e que vai complicar mais do que ajudar em seu projeto. Para piorar, ainda há uma sopa de letrinhas e conceitos que confudem ainda mais o cidadão: BPM, SOA, EBP, Orquestração de Serviços, Coreografia entre Serviços, entre outros.

De fato, a visão de que Workflow está relacionado às questões macro da empresa, envolvendo automatização do seu fluxo de trabalho, é verdadeira, mas, isto é só uma vertente. Não pretendo tocar neste assunto, pelo menos não agora. O que me interessa agora são os desenvolvedores de sistemas, aqueles caras que ouvem as necessidades de seu cliente e que precisam tomar a melhor decisão sobre como desenvolver o sistema do dito cujo. Imagine Arthur Dent, o Analista de Sistemas, ouvindo Ford Prefect, o cliente, dizendo para ele:

– Então, o José recebe a notificação de compra e tem que repassar pro seu gerente.
– Sim, continue… – diz o analista.
– Aí o gerente aprova e repassa pra Carla do almoxarifado ver se tem estoque – diz o cliente, imaginando que já disse tudo e que o sistema já pode começar a ser feito.
– Certo, e a Carla faz o quê?
– Ah sim, já ia esquecendo. Ela aí diz pro financeiro que está certo, que é pra creditar o cliente.

O Analista de Sistemas certamente pensou em Casos de Uso. E o projetista? Imaginou usar Java com Spring, persistir com Hibernate em um banco de dados Oracle com uma arquitetura em três camadas na Web, usando Java Server Faces (JSF). E eles estão errados? Sim! E também não! O que eu defendo é que se pode ganhar bastante em produtividade quando se utiliza uma metodologia diferenciada para projetar e implementar sistemas desta natureza. Mas, para isto, é necessário fortalecer nas pessoas as ideias (conceitos) sobre Workflows. Antes de mais nada, o Arthur Dent precisa ter o feeling, aquela sensação estranha em suas espinhas, algo que lhe diz: eu já vi isto antes! É um Workflow, cara!

“Sim, sabichão, então me indique o caminho das pedras!” Perdoe-me, pois eu não tenho a resposta exata para você. Não agora. Mas, eu estou escrevendo um artigo para o ConSerpro, um Congresso para os empregados do Serpro, sobre este problema e pretendo chegar a algo mais concreto. Percebo no Serpro que as equipes de desenvolvimento perdem a oportunidade de usarem técnicas específicas de projeto e programação para sistemas de Workflow. Não digo apenas usar uma engine de Workflow. Mas, como eu posso ganhar em produtividade quando eu sei que meu sistema é absolutamente um Workflow? Devo usar qual engine de Workflow e de que forma? Qual linguagem de definição de processos devo usar? Pronto. Escolhi a Engine e a linguagem de processos, agora como eu documento este fluxo?

As perguntas são muitas. As respostas, poucas. E as coisas pioram quando percebemos que a padronização na área de Workflows não é grandes coisas. Não é incomum ver engines de Workflow que não conversam entre si: um fluxo definido para rodar em uma, não roda, nem à base de marretadas, em outra. As APIs são absolutamente diferentes também! Agora, imagine tudo isto em uma empresa onde trabalham mais de 1000 desenvolvedores e com centenas de sistemas que poderiam usufruir das facilidades que um mero mecanismo de Workflow pode lhe proporcionar.

Contudo, infelizmente, a realidade não é esta. O que vemos são dezenas de diagramas de projeto e documentos de arquitetura que poderiam ser abstraídos favorecendo uma visão mais generalizada. Vemos centenas de linhas de código, como esta aqui:

public class RegraDeNegocioWorkflowSemNecessidade {
   public void aprovar(Documento documento) {
       if ( documento.getSituacao().getId().equals(SITUACAO_AAPROVAR) ) {
           // Enviar e-mail para o gerente.
           // Atualizar o banco de dados com a situação nova.
          // Chamar um Webservice e aguardar a resposta.
          // Processar a resposta do Webservice e decidir se o fluxo vai pra Aprovado ou Reprovado.
          // Enviar e-mail pro cliente dizendo a situação!
          // Fechar a transação.
          E aqui vai um monte de IF THEN ELSE WHILE FOR...
       }
   }
}

E isto tudo poderia ser descartado! E seu programador poderia ter poupado dezenas de linhas de código, pois todos estes tratamentos podem ser feitos com poucas linhas e uma boa engine ajudando! E você? Concorda comigo? Não? Então, deixe seu comentário!