No início do maio, o InfoQ Brasil participou do Red Hat Summit 2017, onde tivemos uma longa conversa com um dos criadores originais do projeto Drools, Mark Proctor. Mark é Arquiteto de Plataforma de sistemas inteligentes na Red Hat, trabalhando no grupo de projetos do JBoss BPM Suite.
Criado em 2005 como um 'projeto de final de semana', o Drools originou da experiência de Proctor prestando suporte a Analistas de Negócios usando software PeopleSoft. Na empresa (hoje parte da Oracle), ele sentiu a necessidade de criar tecnologias e ferramentas para suportar os hoje chamados 'Desenvolvedores Cidadãos' ou Citizen Developers - profissionais de departamentos externos à TI, que têm conhecimento técnico, mas que são focados no negócio.
A automação de tarefas sem depender do departamento de TI é uma das forças maiores por trás dos projetos:
Em grandes empresas, existem muitas pequenas automações necessárias; há múltiplas coisas que ainda são feitas por e-mail, usando documentos do Word etc., processos que se quer automatizar. Por exemplo, reservar uma sala, solicitar uma nova cadeira, fazer transferências de pessoas entre setores, solicitar laptops - é um número quase infinito de pequenas operações. Mas muitas vezes é inviável passar pelo departamento de TI para cada um desses processos. Então se parte para automatizar dentro do próprio departamento, sem passar pela TI.
O papel de analista de negócios é também fundamental:
Meu trabalho na PeopleSoft era apoiar os analistas de negócios. Trabalhei em uma unidade que não queria trabalhar com o departamento de TI, pois as alterações demoravam muito. Essa unidade treinou os analistas de negócios nos softwares da PeopleSoft. Mas quando eles voltavam do curso, ainda não conseguiam criar seus próprios aplicativos. Era nesse ponto em que eu entrava.
Eu trabalhava com os analistas de negócios para escrever tabelas, páginas, regras. O aprendizado era um processo lento. No início, conseguiam fazer, digamos, 5% do aplicativo sozinhos. Na segunda vez faziam um pouco mais. Depois de seis/nove meses, os analistas com boa bagagem técnica chegavam a fazer 80% da aplicação (ou até mesmo aplicações inteiras, para os casos mais simples). Mesmo assim, quase sempre era necessária a ajuda de engenheiros.
Meu trabalho era basicamente verificar o que estavam fazendo e ajudá-los a corrigir e completar certas partes, chegando a um aplicativo funcional. Mas a ideia principal era apoiar o analista - e não escrever o aplicativo eu mesmo. Era colocar poder nas mãos dos analistas de negócios.
Essa experiência formou a visão do projeto Drools e depois de boa parte da suíte de projetos JBoss BPM:
Estamos tentando avançar em direção a um ambiente 'Low Code', que permite a analistas de negócios técnicos escrever aplicações eles mesmos, com o apoio de engenheiros. Essa é a nossa visão, ainda não chegamos lá. Atualmente, com os projetos do JBoss BPM, um analista de negócios poderia, talvez, criar o fluxo BPM e definir algumas tarefas e formulários - mas o engenheiro ainda desenvolveria o aplicativo como um todo.
Nosso trabalho atual concentra-se em inverter essa equação. Em vez de o engenheiro construir o aplicativo e o o analista de negócios preencher algumas partes, queremos colocar o analista de negócios no controle. O engenheiro passa a apenas preencher algumas lacunas. Essa é a nossa visão!
O JBoss BPM é constituído de uma série de subprojetos, sendo as principais tecnologias o mecanismo de workflow e o de regras de negócios. Essas tecnologias, juntamente com o Java EE e outras APIs focadas na experiência do usuário e integração, são base de um conjunto de módulos integrados. São incluídos um modelador de dados, um editor visual de processos BPMN e um editor visual de formulários, entre outros. Veja a arquitetura geral nesta imagem, extraída da documentação do jBPM:
.png)
Proctor coloca essas principais tecnologias no contexto geral:
Ao resolver problemas de negócios, nunca há uma ferramenta única para fazer tudo. Existem pelo menos dois aspectos fundamentais na maioria dos sistemas complexos: as regras e os fluxos de trabalho (workflows). Estes dois quase sempre vêm juntos. No Drools temos um mecanismo de regras; o jBPM faz workflow/orquestração.
Com a evolução do projeto, expandimos para incluir outras ferramentas como o OptaPlanner que acrescenta técnicas avançadas de otimização, além do DashBoard Builder, para criação de relatórios e painéis de controle. Hoje temos uma conjunto de projetos integrados que formam uma 'suíte'.
Essa suíte de ferramentas e tecnologias está hoje em um projeto open source guarda-chuva chamado "KIE":
Queríamos ter um nome para identificar nossa plataforma; escolhemos "KIE", abreviação de "Knowledge is Everything". Pode-se dizer que o KIE é uma plataforma de engenharia do conhecimento.
Proctor coloca o uso das ferramentas no contexto real de automatizar um processo de negócio:
Geralmente começamos criando o diagrama de workflow usando o editor de diagramas; com isso é codificado o workflow e a orquestração usando como base o jBPM. Dentro desse fluxo, haverá pontos onde decisões devem ser tomadas. É aí que entram as tabelas de decisão, criadas com o Drools.
Em um exemplo: imagine que há uma série de requisitos para transferir um empregado para outro departamento. Provavelmente vai haver uma parte de aprovação manual pelo departamento de RH, mas várias tarefas poderão ser automatizadas - por exemplo, a verificação dos requisitos básicos necessários para a transferência.
Em resumo: o Drools ajuda na tomada de decisões, na validação, no enriquecimento de dados; o jBPM trata do do princípio ao fim dos processos. Com o KIE, trabalhamos para simplificar essa definição e facilitar a automatização e a implantação em um runtime.
Um dos aspectos mais interessantes do KIE é que, por trás de grande parte dos projetos, estão técnicas sofisticads de inteligência artificial e de sistemas cognitivos:
Embora tenha falado sobre aplicações de negócios e seus elementos (ex. tabelas de decisão, formulários, workflows), os mecanismos subjacentes são muito mais poderosos do que essas funcionalidades indicam. Eles têm base na inteligência artificial clássica. Estamos trabalhando, por exemplo, com processos flexíveis ad hoc, uma técnica que pode formar a base de sistemas cognitivos. Esse é um tema importante da nossa pesquisa.
O núcleo da Inteligência Artificial é a representação de conhecimento. Consultando um dos livros clássicos da área, de Norvig / Russel (Artificial Intelligence, a Modern Approach"), vemos um capítulo sobre otimização e planejamento; isso é o OptaPlanner. Há também um capítulo incluindo temas como forward/backward chaining; esse é o Drools… E assim por diante!
O núcleo do KIE se baseia em representar seu mundo e como raciocinar sobre ele declarativamente. Isso impulsiona boa parte de nossa pesquisa: tentamos encontrar maneiras de expor essas técnicas e torná-las úteis para os usuários de negócios e os desenvolvedores.
Complementando essa ideia, temos a ideia de Low Code que já citei: os formulários, relatórios… Estes, claro, não usam IA, mas são necessários para complementar as aplicações de negócios.
Com tabelas de decisão e fluxos ad hoc, temos a base de um sistema de engenharia do conhecimento que suporta a criação de sistemas cognitivos sofisticados.
Uma nova versão estável do KIE está perto de ser lançada, e será provavelmente identificada como 7.1.0. Todo o desenvolvimento é realizado abertamente no repositório do Github. Além de muitas novas funcionalidades, o release traz mudanças grandes na interface com o usuário e na experiência geral de uso. Também foi aperfeiçoada a integração entre os múltiplos componentes.
Pode-se conhecer mais sobre o KIE e o JBoss BPM em www.kiegroup.org e consultando a documentação da versão mais recente do jBPM. Além disso, a integração com o Eclipse através do componentes de BPM do JBoss Tools permite modelar processos usando as tecnologias do KIE no próprio IDE.