as regras de negócios vêm em primeiro lugar

recentemente, colegas e eu estávamos conversando com o desenvolvedor-chefe de software em uma grande organização cliente sobre o progresso em um grande esforço de reengenharia lá. Nossa preocupação era se os membros da equipe do projeto poderiam cumprir um prazo de cerca de nove meses para entregar um protótipo em grande escala. Acabamos de passar vários meses intensivos desenvolvendo um modelo de negócios abrangente, e eles ainda tinham vários meses de design de sistema para serem concluídos.

este desenvolvedor chefe é muito afiado – não se comprometer com qualquer resposta levemente. Por mais tempo, ele não disse nada, perdido no pensamento. Finalmente, observando os diagramas de negócios detalhados rebocados nas paredes ao redor, ele disse: “Se já tivéssemos começado a codificar, eu diria que não tínhamos chance alguma. Mas como ainda não começamos a programar, eu diria que as chances são muito boas.”Eu tive que correr isso várias vezes em minha mente antes de pegar seu significado. “Se já tivéssemos começado a codificar, eu diria que não tínhamos chance alguma.”

eu sabia que ele achava que a codificação do aplicativo em si seria muito difícil. Envolveria o uso de um mecanismo de regras, uma rede de distribuição mundial, interfaces gráficas de usuário e algum middleware significativo.

ele estava dizendo que se eles tivessem que resolver todos os problemas de negócios durante a codificação, eles nunca conseguiriam a tempo—ou provavelmente nunca. No entanto, como a equipe do projeto estava lidando com os difíceis problemas de negócios antecipadamente (incluindo a especificação das regras de negócios), ele achou que eles tinham uma boa chance de concluir o código até a data-alvo.

em grande parte, a abordagem de regras de negócios é simplesmente fazer as perguntas certas das pessoas certas. Existe apenas uma maneira de cumprir honestamente um prazo—e isso é resolver o problema de Negócios Primeiro.

TI orientada para negócios

nos primeiros dias da construção de sistemas de negócios, o lado comercial poderia essencialmente sentar e apenas deixá-los acontecer. As vantagens de automatizar eram tão convincentes que você não podia fazer praticamente nenhum erro. Agora, para todos os fins práticos, os negócios e a ti operam inseparavelmente. Ao realizar projetos, o passo lógico seria reunir equipes de projetos de negócios/TI e fazer com que elas sigam uma abordagem orientada para os negócios para o desenvolvimento de requisitos. No entanto, muitas empresas não estão nem perto de fazer isso hoje.

muitas vezes, o lado do negócio ainda produz “requisitos” difusos e pouco focados, e o lado da TI continua fazendo “requisitos” apenas um ou dois pontos acima da programação. Como essa lacuna entre profissionais de negócios e profissionais de TI no desenvolvimento de requisitos pode ser eliminada?

a resposta é relativamente simples. A empresa precisa de uma abordagem organizada que permita aos profissionais de negócios impulsionar o desenvolvimento de requisitos. Essa abordagem deve fornecer um roteiro que mostre como fazer os tipos certos de perguntas sobre as coisas certas nos momentos certos. O que é necessário é uma abordagem orientada para os negócios.

nas abordagens tradicionais de desenvolvimento, muito geralmente é perdido na tradução de requisitos iniciais para o sistema em execução real. Mas escrever um conjunto de regras de negócios claras melhora as comunicações entre o lado comercial e a TI e fornece uma ponte entre a análise de negócios e o design do sistema. A abordagem de regras de negócios ajuda a fechar a lacuna de requisitos entre o lado comercial e o lado de TI.

então, o que é uma regra de negócios? Do ponto de vista comercial, é uma diretiva destinada a influenciar ou orientar o comportamento. As regras de negócios são literalmente o conhecimento codificado de suas práticas de negócios. Do ponto de vista de TI, uma regra de negócios é uma peça atômica de lógica de negócios reutilizável.

de certa forma, todo mundo sabe quais são as regras de negócios—elas são o que guiam sua empresa na execução de suas operações diárias. Sem regras de negócios, você sempre teria que tomar decisões em tempo real, escolhendo entre alternativas caso a caso. Fazer as coisas dessa maneira seria muito lento.

regras são familiares para todos nós na vida real. Jogamos jogos por regras, vivemos sob um sistema legal baseado em um conjunto de regras e estabelecemos regras para nossos filhos. No entanto, a ideia de regras nos sistemas de negócios é ironicamente estranha à maioria dos profissionais de TI. Diga “regras” e muitos profissionais de TI pensam vagamente em sistemas especializados ou inteligência artificial. Há pouco reconhecimento de como as regras centrais realmente são para as operações básicas do dia-a-dia do negócio.Não coincidentemente, muitos trabalhadores e gerentes do lado empresarial tornaram-se tão bem doutrinados em visões processuais para o desenvolvimento de requisitos que pensar em termos de regras pode parecer estranho ou abstrato. Praticamente toda metodologia é culpada nesse sentido, seja para reengenharia de processos de negócios, desenvolvimento de sistemas ou design de software.

isto é lamentável por duas razões:

1. Pensar em qualquer atividade organizada em termos de regras é realmente muito natural. Por exemplo, imagine tentar explicar um jogo como xadrez, damas, beisebol ou futebol sem explicar as regras.

2. Os trabalhadores e gerentes do lado empresarial têm o conhecimento necessário para criar boas regras.

regras de amostra

dê uma olhada nas regras de amostra que se seguem e observe como todos os aspectos do controle operacional em um sistema de negócios podem ser tratados por regras:

• restrições: Um cliente não deve colocar mais de três ordens de pressa cobradas em sua conta de crédito.

* heurística: Um cliente com status preferido deve ter seus pedidos preenchidos imediatamente.

• cálculos: o volume anual de pedidos de um cliente deve ser calculado como o total de vendas fechadas durante o ano fiscal da empresa.

• inferência: um cliente deve ser considerado preferido se o cliente fizer mais de cinco pedidos acima de US $1.000.

• Timing: um cliente deve ser arquivado se o cliente não fizer nenhum pedido por 36 meses consecutivos.

• gatilhos: “enviar aviso prévio” deve ser executado para um pedido quando o pedido é enviado.

regras construir diretamente em termos e fatos. Termos—como cliente, Remessa e fatura-devem ter uma definição precisa e inequívoca no negócio. Por exemplo, o cliente pode ser definido como: “uma organização ou pessoa individual que fez pelo menos um pedido pago durante os dois anos anteriores.”

os fatos são dados por frases simples e declarativas que conectam os Termos a um verbo ou frase verbal, como “o cliente faz o pedido.”

um “modelo de fato” é um conjunto de declarações de fato que descrevem os resultados de uma operação comercial. Um modelo de fato deve servir como um modelo inicial para um modelo de dados, mas seu objetivo principal é capturar o conhecimento sobre o negócio de forma estruturada, destilado dos trabalhadores e gerentes do lado do negócio que o possuem.

as regras essencialmente acrescentam o sentido das palavras devem ou não aos Termos e fatos, como em “ordens a crédito acima de US $1.000 não devem ser aceitas sem uma verificação de crédito.”

as regras devem ser expressas em Inglês comercial claro, inequívoco e bem estruturado, começando com um assunto explícito. As regras não devem ter penugem e nem fatos ausentes. As regras podem ser qualificadas, como em ” uma remessa deve ser segurada se o valor da remessa for superior a US $500.”E as regras podem incluir critérios de tempo, como em” um aluno deve estar matriculado em pelo menos dois cursos até o encerramento da inscrição.”

Independência de regra

um negócio é muito parecido com um corpo humano. A estrutura do conhecimento (termo e fato) é como o esqueleto; os processos são os músculos poderosos; e as regras são o sistema nervoso que controla os outros dois. Todos os três são essenciais e inter-relacionados. Mas as regras de negócios devem ser separadas das outras duas. Um princípio básico dessa abordagem é que as regras são independentes de processos e procedimentos. Um benefício marginal dessa “independência de regra” é uma enorme simplificação nos processos.

o resultado é um” processo fino”, um objetivo de longa data de muitos profissionais de TI. Ao retirar as regras dos processos, você pode produzir processos relativamente simples e que podem ser alterados conforme a necessidade surgir.

na Liga Nacional de futebol, se uma peça não estiver funcionando para uma equipe, ela sairá de sua playbook em alguns jogos. As peças são essencialmente jogadas. Da mesma forma, as empresas precisam ver seus próprios procedimentos como vias de lançamento—baratos o suficiente para descartar e substituir prontamente quando os procedimentos não funcionam mais bem.

os procedimentos de descarte são essenciais para que o negócio seja adaptável e competitivo. Essa ideia enganosamente simples-possibilitada pela abordagem de regras de negócios—pode revolucionar a maneira como o trabalho é feito e os sistemas são projetados.

reimpresso com permissão de Principles of the Business Rule Approach, por Ronald G. Ross (Addison-Wesley, 2003). Ross é co-fundadora e diretora da Regra de Negócio Solutions LLC e editor-executivo do site BRCommunity.com.

modelo de fato de biblioteca
este diagrama mostra um modelo de fato gráfico para uma biblioteca. A redação da regra é baseada diretamente no modelo de fato, que é um diagrama de conceitos básicos de negócios – uma estrutura de conhecimento. Um modelo de fato pode e deve fornecer um modelo de primeiro corte para como os dados serão eventualmente organizados em um banco de dados. REGRA: Um cartão de biblioteca pode ser usado para verificar um livro somente se o livro for de propriedade de uma biblioteca para a qual o cartão está autorizado.