Este artigo se concentra em dois desses problemas: a carga operacional de executar o ODM e o custo do vocabulário que mantém os usuários de negócio dependentes dos desenvolvedores. Cada problema é mostrado como aparece no ODM e como é resolvido no DecisionRules.
Os padrões descritos são independentes do setor. Eles se aplicam tanto a regras de elegibilidade para empréstimos quanto a subscrição de seguros, pacotes de telecomunicações ou benefícios governamentais.
O que é um motor de regras de negócio?
Um motor de regras de negócio (BRE) existe por um motivo: tornar as decisões de negócio automatizadas baratas, rápidas e seguras de alterar. As decisões pertencem ao negócio. O BRE permite que o negócio assuma seu controle.
O BRE certo comprova seu valor com um teste simples: um gerente de produto, responsável por compliance ou responsável por riscos pode abri-lo, ver o que está atualmente em production, alterar um limiar e implantar a mudança sem abrir um ticket para um desenvolvedor. É isso que «automação» realmente significa.
Um BRE que cria novas funções especializadas, novos pipelines de implantação e nova infraestrutura para manter está resolvendo o problema errado.
Problema 1: A carga de infraestrutura
No ODM
Uma implantação não é um único produto, mas uma stack: um servidor de aplicações como WebSphere, Liberty, JBoss, WebLogic ou Tomcat, um banco de dados relacional para o repositório de regras, Decision Center como ambiente de criação, Decision Server como tempo de execução, vários arquivos implantáveis, configurações de perfil, clusterização opcional para alta disponibilidade e um ambiente dedicado para cada estágio.
Cada ambiente do ODM inclui uma stack completa que a equipe instala, mantém com patches e replica para cada estágio.
A aplicação de patches, as atualizações e o planejamento de capacidade acontecem internamente. O conjunto de habilidades necessário abrange administração de WebSphere, funcionamento interno do ODM e integração corporativa com Java. Essas são áreas especializadas, com seu próprio mercado de talentos. Os usuários de negócio podem criar regras no Decision Center, mas a implantação subjacente continua sendo responsabilidade de desenvolvedores e administradores de sistemas.
No DecisionRules
A plataforma é oferecida como serviço gerenciado. As opções são Public Cloud, SaaS na AWS com regiões nos Estados Unidos ou na UE; Private Managed Cloud, um ambiente dedicado em uma região escolhida pelo cliente, normalmente disponível em poucos dias; ou Self-Hosted, uma implantação em Docker ou Kubernetes, inclusive air-gapped.
As três opções usam a mesma UI, as mesmas APIs e o mesmo conjunto de habilidades.
Os três modelos de implantação compartilham a mesma UI, as mesmas APIs e o mesmo conjunto de habilidades.
Com Public Cloud e Private Managed Cloud, o cliente não precisa instalar, aplicar patches nem escalar nada. O DecisionRules opera a plataforma de ponta a ponta.
As implantações Self-Hosted consistem em um único contêiner e uma instância do MongoDB gerenciada pela equipe. Mesmo assim, o servidor de aplicações, o console de criação separado e a replicação da stack por estágio deixam de existir.
Problema 2: O custo do vocabulário
No ODM
Os usuários de negócio não escrevem regras em inglês livre. Eles montam as regras a partir de um vocabulário controlado que os desenvolvedores prepararam antecipadamente. A cadeia tem quatro camadas, e três delas ficam atrás de uma barreira que o usuário de negócio não pode atravessar.
Três das quatro camadas ficam atrás de uma barreira que somente um desenvolvedor pode atravessar.
Quando um usuário de negócio precisa de um conceito que ainda não existe no vocabulário, como um novo indicador, um novo cálculo ou um novo campo, um desenvolvedor deve ampliar o XOM, atualizar o BOM, verbalizar o novo elemento e republicá-lo antes que a frase apareça no menu suspenso. O vocabulário também exige manutenção contínua: as verbalizações padrão nem sempre são claras para o negócio, BOMs grandes produzem vocabulários difíceis de gerenciar que deixam o editor mais lento, e os desenvolvedores gastam tempo real fazendo ajustes com Categories e Virtual Methods.
No DecisionRules
O modelo é reduzido a duas camadas. Os esquemas de entrada e saída da regra formam o vocabulário. O esquema e a regra ficam no mesmo ambiente, são editados pelas mesmas pessoas e passam pelo mesmo ciclo de revisão.
O esquema e a regra ficam no mesmo ambiente, por isso um novo campo fica disponível assim que existe.
Quando um campo existe no esquema, ele fica imediatamente disponível como coluna de condição ou coluna de saída na tabela. Não há um modelo de objetos separado, uma etapa de verbalização nem um ticket para um desenvolvedor disponibilizar uma nova variável.
Um exemplo real: Bônus acumulado
Esta é uma regra real do ODM, proveniente de um projeto de cálculo de bônus. A intenção de negócio cabe em uma frase: quando um funcionário tem prêmios SMART e prêmios SYNERGY, os valores dos bônus SMART são somados e o total é acrescentado a cada prêmio SYNERGY.
O inglês legível visto por um analista se apoia em uma classe Java que um desenvolvedor escreveu antecipadamente.
Ao abrir essa regra no Decision Center, o código da captura de tela não aparece. A visualização BAL apresenta um inglês legível que o analista pode editar:
for each award in smart awards do set 'smart total' to smart total + the bonus amount of the award;
for each award in synergy awards do set the bonus amount of the award to the bonus amount of the award + smart total;
A redação é fluida. É possível alterar um limiar, adicionar uma condição ou renomear uma categoria. Essa parte não é o problema.
O mais difícil é alterar o conteúdo do menu suspenso.
Cada frase exibida nessa BAL, como «the bonus amount of the award», «smart awards» ou «synergy awards», só existe no menu suspenso porque um desenvolvedor escreveu uma classe Java para Award, adicionou a ela um campo bonusAmount , disponibilizou-a por meio de um Business Object Model e escreveu manualmente a verbalização em inglês. Se, no dia seguinte, o negócio quiser adicionar um regional bonus modifier à regra, não poderá fazer isso diretamente.
A fluidez é real, mas funciona dentro do vocabulário preparado pelo desenvolvedor.
A mesma regra no DecisionRules permanece sob seu controle
No DecisionRules, a mesma intenção de negócio é implementada por um Decision Flow que chama uma Decision Table. Ambos são criados no navegador. Ambos permanecem sob seu controle.
O Flow torna a orquestração legível, e a tabela contém a decisão para cada prêmio. Ambos podem ser editados no navegador.
O Flow superior mostra todo o algoritmo de uma só vez: agrega o total SMART uma vez, percorre a lista de prêmios, chama a tabela abaixo para cada prêmio e coleta os resultados na saída. Esse limite marca o momento da delegação. O Flow deixa de cuidar da orquestração nesse ponto, e a tabela assume a decisão para cada prêmio.
Essa tabela é o núcleo da regra e permite entender seu funcionamento em uma única leitura. Os prêmios SYNERGY recebem o total SMART em seus bônus, e todo o restante, ELSE, permanece igual. Para alterar o limiar de «maior que 0» para «maior que 100», basta modificar a célula e republicar. A inclusão de uma terceira linha para um novo tipo de prêmio funciona da mesma maneira: a linha é adicionada, as células são preenchidas e a regra é publicada. Não é necessário um desenvolvedor, uma classe Java nem um ticket.
O Flow acima da tabela justifica sua presença ao tornar a orquestração legível. A etapa de agregação é um nó que qualquer pessoa pode apontar. A iteração é outro nó. A decisão para cada prêmio é um nó, e esse nó é a tabela descrita acima. O nó de coleta indica exatamente onde o resultado é armazenado. Nada fica oculto em um formulário gerado que ninguém consegue editar.
O que acontece com o modificador regional de bônus que fica bloqueado no ODM? O ponto não é que essa regra seja difícil. Até uma regra pequena chega a um limite quando precisa de um conceito que o desenvolvedor não disponibilizou antecipadamente. No DecisionRules, essa barreira não existe porque a camada que a cria também não existe.
Correspondências: A tradução entre as plataformas
A migração é uma tradução, não uma reescrita. ODM e DecisionRules oferecem vários tipos de regra, e cada artefato do ODM usado atualmente tem um equivalente no DecisionRules.
Na maioria das regras, o tipo é traduzido diretamente: uma Decision Table do ODM se torna uma Decision Table do DecisionRules, e um Decision Tree do ODM se torna um Decision Tree do DecisionRules.
A imagem abaixo não trata da quantidade de tipos de regra. Ela mostra em que cada tipo se apoia, onde é criado, como é executado e o que precisa ser mantido para continuar funcionando. A parte superior da stack é traduzida, e a inferior desaparece.
A parte superior da stack é traduzida diretamente, e a parte inferior desaparece por completo.
Artefatos de regras
Cada tipo de regra no ODM se apoia em um Business Object Model que envolve um Java Execution Object Model. Cada propriedade e método é verbalizado manualmente para formar o vocabulário que o autor vê. Cada tipo de regra no DecisionRules se apoia em um esquema JSON tipado, declarado na mesma UI que a regra. A intenção de negócio é a mesma nos dois sistemas, mas o DecisionRules utiliza metade das camadas.
Separadamente, o artefato de orquestração Ruleflow do ODM, com seu arquivo XML `.rfl`, torna-se um Decision Flow em uma tela visual.
Onde o trabalho acontece
O ODM divide a criação de regras entre duas ferramentas: os usuários de negócio abrem o Decision Center no navegador, e os desenvolvedores abrem o Rule Designer no Eclipse. O DecisionRules reúne as duas funções em um único ambiente de navegador, no qual trabalham lado a lado nos mesmos artefatos.
Usuários de negócio e desenvolvedores trabalham nos mesmos artefatos, em vez de usar duas ferramentas separadas.
Como as regras são executadas
O Rule Execution Server é executado em uma instância do WebSphere que a equipe instalou e mantém com patches. Assim que é publicada, uma regra do DecisionRules fica disponível como endpoint REST em uma URL da Solver API. O formato do contrato usado pela aplicação não muda. Apenas o endpoint e o protocolo são alterados.
O que precisa ser mantido
Esta linha desaparece por completo. A instalação do WebSphere, o banco de dados relacional que contém o repositório de regras, as réplicas por estágio para dev, SIT, UAT e production, os scripts de clusterização e os ajustes no vocabulário desaparecem nas implantações de nuvem gerenciadas escolhidas pela maioria das equipes. A palavra «Nothing» no canto inferior direito da imagem não é um recurso retórico. Ela representa literalmente a superfície operacional assumida após a migração.
A migração não acontece sem apoio
Lida de cima para baixo, a imagem conta a história da migração de uma só vez. A lógica de decisão é transferida sem alterações. A tradução é mecânica na metade superior e representa uma eliminação na metade inferior. Essa assimetria faz a migração valer a pena.
A migração não acontece sem apoio. Nossa equipe analisa o ambiente do ODM, define um plano de migração em conjunto com o cliente e depois usa nosso AI Assistant, que conhece a plataforma DecisionRules de ponta a ponta, para ajudar a implementar as regras com rapidez e consistência. Isso reduz os erros de transcrição manual que, de outra forma, se acumulariam em uma migração de grande porte.
Quando já existe um conjunto de testes do Decision Validation Services, os casos são traduzidos junto com as regras e executados nas novas versões do DecisionRules. Assim, a equivalência pode ser verificada antes da transição. Quando não existe um conjunto de testes, o AI Assistant cria um a partir da própria lógica da regra. Isso oferece uma rede de segurança contra regressões que talvez não existisse no ODM.
A intenção de negócio vem do cliente. Nós fornecemos a tradução e a verificação.
IBM, Operational Decision Manager, ODM, WebSphere, Decision Center, Decision Server, Rule Designer e Decision Validation Services são marcas comerciais ou marcas registradas da International Business Machines Corporation nos Estados Unidos e/ou em outros países. Todos os demais nomes de produtos mencionados pertencem aos seus respectivos proprietários. Este artigo não é endossado pela IBM Corporation nem afiliado a ela.
Ivan Peresta trabalha na DecisionRules, onde seu papel abrange análise de produto, serviços profissionais e suporte ao cliente. Ele participa de todo o ciclo de vida das funcionalidades do produto, desde o design inicial e pensamento de UX até testes práticos, documentação e entrega voltada ao cliente. Seu trabalho faz a ponte entre o desenvolvimento do produto e as pessoas que realmente o utilizam, seja ajudando um cliente a projetar seu sistema de regras ou garantindo que um novo recurso seja lançado com orientações claras e exemplos funcionais.