业务规则管理系统

引言

自1994年以来，Standish Group进行的重复性两年期调查显示，近四分之三（73.3%）的美国软件开发项目失败，原因包括在开发周期中的某个时刻被取消（25.9%）、超出预算或预估时间，以及提供的功能比最初设定的要少（47.4%）。

导致成本和时间超支的主要原因之一是重启，即每启动100个项目，就有94个项目需要重启（这并不意味着100个项目中有94个会重启一次，有些项目可能会重启多次）。

项目失败的原因（按因素顺序）

• 需求不完整
• 缺乏用户参与
• 资源不足
• 不切实际的期望
• 缺乏高层支持
• ....

列表中的几项都指向许多IT开发组织以开发为中心的企业文化。开发人员经常期望用户学习他们的语言，以流程图或UML图的形式。这是一个错误。项目团队必须基于领域简单的概念模型开发语言，用用户和开发人员都能理解的简单术语编写。在当今快速发展的竞争环境中，BRMS在解决IT面临的这一挑战方面发挥着作用。

此外，维护成本：所有软件开发成本的85%发生在产品发布后，其中80%的维护是由于未满足或预料到的用户需求，只有20%是由于错误或可靠性问题。变更成本在定义阶段为1个单位，在开发阶段为1.5到6个单位，发布后为60到100个单位（Pressman）。

从开发人员的角度来看，面向对象开发如此吸引人的原因之一是：如果维护局限于更改对象，这些更改不会传播到其他对象。然而，当业务规则分散在应用程序各处或与接口定义紧密耦合时，这种优势就不再适用。典型的变更涉及众多人员和多种流程，以确保业务变更已被翻译并体现在业务应用程序中。

业务政策的变化很大程度上受到市场变化的影响，企业必须对不同的竞争对手做出反应，并迎合越来越多的不同客户。比竞争对手更快地对变化做出反应非常重要，而且反应时间每天都在缩短。随着时间的推移，变化和反应时间的结合给信息技术团队带来了更大的压力。

业务规则管理系统（BRMS）来帮忙

如今，行业中有许多产品声称具有解决复杂处理问题的功能。也有一些技术允许开发基于规则的处理系统。像“lisp”和“prolog”这样的规则编程语言已经存在了几十年。Java正被用来复制早期专家系统语言和规则编程语言所提供的功能和特性。

另一个解决方案是将策略的定义从实现和代码细节中分离出来，并将它们放在一个中心位置（规则空间）。BRMS就是这样做的。BRMS是用于外部化业务规则并提供集中式业务规则管理功能的系统。这解决了当今企业面临的紧迫需求：更改业务规则以适应快速变化的业务环境，并克服缓慢IT变革周期的限制性。

基于规则的应用程序

基于规则的应用程序是使用规则来提供建议或诊断，或在特定情况下确定行动方案或解决特定问题的计算机应用程序。

BRMS允许基于规则的应用程序

• 捕获易于频繁更改的策略和规则
• 在业务应用程序中快速轻松地实现这些更改
• 以熟悉的业务语言管理和编写规则
• 业务用户可以按照自己的时间表更新软件，而不是IT部门。

基于规则的应用程序的成功在于业务逻辑——业务的策略和知识——从应用程序逻辑中抽象出来；通过企业级技术架构将它们暴露给整个企业。这使得创建和更改业务逻辑的过程更加容易。业务用户请求的相同更改可以在不更改程序代码的情况下实现，只需隔离更改并仅测试已修改的规则。基于规则的应用程序通常更容易维护且成本更低，因为不必为业务流程的每次微小更改重新设计、重新测试、重新编译和重新部署代码。

BRMS的常见功能

任何BRMS的关键组成部分是业务规则，业务规则没有标准的定义，可以这样说：“它是管理或约束业务某个方面的陈述”。它在“原子性”的意义上是不可进一步分解或细分的更详细的业务规则。如果进一步细分，将会丢失有关业务的重要信息。因此，业务规则本质上是组织经营业务的策略。

规则

BRMS中的规则具有声明式、非过程化的特点；它们说明什么为真，而不是如何计算。规则通常表示为 **IF** ... **THEN** ..语句，例如

IF A THEN B

其中A称为前件，B称为后件。在表达规则时，后件通常是行动或结论。通常，一个规则可以有多个前件，通常由AND或OR组合。同样，一个规则可以有多个后件，这通常表明需要采取多个行动。

规则的一个例子可能是

• 如果驾驶员年龄小于17岁，则拒绝所有租车请求。
• 如果一项索赔涉及价值至少1000美元的物品丢失，则该索赔至少有较低的欺诈可能性。

规则也可以以其他格式指定，通常倾向于使用国内（必须或不得）的形式来表达约束或推论，例如

• 信贷申请人必须年满21周岁。
• 采购订单在签收前不得开票。

对于许多企业来说，可能使用成百上千条这样的陈述来表达其业务政策、程序和规定，这些都约束着它们的业务运营。

规则引擎

不同规则的组由规则引擎指定和处理，专注于将业务逻辑与控制逻辑分离。它使用规则和事实，并将它们结合起来得出结论。事实代表系统的输入，用于得出结论或触发操作，例如客户信息、发票。

分析后，引擎可以返回结果和/或调用操作。这些结论通常是通过演绎法得出的，尽管还有其他可能的途径。结果可以是简单的数据值或复杂的数据结构。操作几乎可以是任何事情，包括发送电子邮件。

规则存储库

基于规则的处理模型必须提供规则存储库，这是一个集中式位置，所有业务逻辑都存储在此，为系统开发各个阶段的轻松迁移和转移创建一个平台。

规则存储库提供了存储规则定义的各种版本并记录更改历史的可能性，并支持规则的版本控制。

这还允许

• 审计规则的能力
• 规则的多个版本定义

规则模板

规则模板是规则的设计模式。在许多情况下，一个规则可能适用于多个数据。在这种情况下，规则模板允许创建带有待以后填写的空槽的规则。业务规则模板代表一个部分定义的业务规则，其中包含缺失信息的占位符槽。模板可用于创建多个具有相似结构的规则，其中只有槽中填充的值有所不同。

规则语法检查

一个好的BRMS将提供实时检查规则语法的工具，在输入规则时，使用结构化的规则语言。

以自然语言管理对象

在业务规则的上下文中，形式化表示是一个开放性问题；BRMS必须提供一种形式化语言，该语言结合了足够的表达能力、高效的推理支持和自然的表达方式，使普通用户能够理解和个性化其系统的策略。

有必要提供用户友好的前端，以用户熟悉的语言（如图形语言或自然语言）来阐释策略。

BRMS产品

市面上有几种规则引擎，包括商业和开源的选择。商业规则引擎通常允许您使用专有的类英语语言来表达规则。其他则允许您使用Groovy或Python等脚本语言编写规则。

从众多候选系统中，我们必须进行筛选。我们应用的标准是，入围的产品应该

• 允许业务分析师创建和修改规则
• 使用功能齐全的存储库
• 允许应用程序部署在面向服务的架构中
• 允许规则引擎成为更大型应用程序的组件或服务

产品

• **Smart Rules**，Kontac
• **CLIPS**，NASA
• **JRules**，ILog
• Jess，Sandia National Laboratories
• **JBoss Rules**，JBoss
• **Blaze Advisor**，Fair Isaac

结论

使用规则引擎可以显著降低应用程序中实现业务规则逻辑的组件的复杂性。与不使用规则引擎的应用程序相比，使用规则引擎来表达规则的应用程序更具声明性和可扩展性。正如您所见，这种方法更有可能更易于维护。