|
随着企业信息化程度的提高，业务对IT的依赖程度也越来越高，但IT部门与业务部门之间的矛盾却始终存在：软件开发人员善于编写代码，但他们对业务规则却知之甚少；同样，业务人员熟知业务规则，但却很难将它们转换成详细的需求文档。业务规则管理系统（BRMS）可以把对逻辑甚至代码的控制权交给业务人员，从而弥合业务部门和IT部门之间的差异。
业务规则管理系统（Business Rule Management
System）源自以下想法：开发人员把应用软件的业务逻辑与数据验证逻辑及工作流控制相隔离，形成独立的业务逻辑容器——BRMS，随后业务人员就可以用简单的类似英文的编程语言为业务规则“编写代码”。主要的BRMS产品包括：ILOG的JRules、Fair
Isaac的Blaze Advisor、Corticon Decision Management
System和Production Systems Technology（PST）公司的OPSJ系统以及微软为BizTalk
2004推出的业务规则框架（Business Rules Framework）。
BRMS引擎通常嵌入在垂直行业的企业应用软件中，诸如处理保险、贷款申请、复杂调度以及其他一些需要业务人员干预的事务处理软件。这种处理方式的优点很明显：业务人员直接控制企业应用软件的运行规则，用不着总是请求IT人员的支持，如果业务人员认为业务规则需要修改，他自己就可以完成，完全不必等待IT人员抽时间来处理。如此一来，IT系统的维护成本降低了，也提高了业务规则实施的效率。
打破逻辑僵局
首先让我们来看一下企业应用软件的更改过程。通常情况下，业务人员对企业应用软件的熟悉程度远不如对桌面软件熟悉，因此，如果业务人员想建立新应用或者想对现有应用进行更改，就必须向IT部门提出申请，而后者可能对业务人员所谈论的东西一无所知。于是，业务部门与IT部门之间开始进行多轮会谈以达成共识。
随后，开发人员开始编写代码，他们要么把业务规则写入软件组件，要么将它们嵌入数据库过程中。测试后的应用代码被交回给业务人员进行确认，但不幸的是，这一结果很可能因为不符合业务人员原来提出的需求而遭到拒绝。经过多次反复和代码重写之后，业务人员最终拿到的也仅仅是勉强可以接受的代码。
有了BRMS，情况就完全不同了！业务人员可以决定并编写业务逻辑，只要他们知道如何用英文编写规则即可。一条业务规则通常是这样的：“如果（IF）”某些事件发生或某些条件存在，“那么(THEN)”就会发生某些事件，“否则(ELSE)”会发生其他事件。每个IF-THEN-ELSE语句就是一条业务规则。每条规则都是说明性的，而且可以与其他规则互相作用。BRMS允许业务人员查看、分析、编写及维护这些规则，基本上不需要IT人员的帮助。
BRMS会不断“斟酌”规则，直到解决方案出来。它会反复地遍历规则，直到没有可以执行的规则为止。其整个思路是：数据的变动决定规则的执行方式，而互相作用的规则可以减少对人员干预的需求。例如，相关的一组规则可以控制贷款申请、保险政策、运输商选择等。
相比之下，在传统的应用软件开发中，规则是以自上而下的方式编排的，极易出错。例如，如果某条规则的THEN部分改动了另一条规则的IF部分所用的数据，那么必须检查整个流程，看看如何合理地编排规则。这就是为什么使用普通的应用软件开发方法编写、改动及维护业务规则会很费时间。
把规则嵌入基础设施
从功能框图层面上看，BRMS驱动的应用软件酷似传统的企业应用软件（如图所示）。BRMS就像由Web服务器、应用服务服务器和数据库组成的多层结构系统中的第四层，它把控制逻辑交给业务人员。由于类似英文的BRMS语句浅显易懂，因此连CEO都可以来查看规则。任何规则都可以被改动、增添或删除，或者交给IT部门进行集成和测试，然后在短短几天甚至几小时内便可投入生产。
虽然采用BRMS系统之后，企业有望在变更管理方面大大节省开支，但同时也需要在BRMS开发及培训方面投入大笔初期投资。要评估编写业务规则需要多长时间几乎是不可能的，因为这取决于要编写多少条规则——而这免不了会超出原先的预计；另一方面，一想到为业务规则“编写代码”，业务人员很可能会犹豫不决。
是否使用BRMS取决于应用软件的类型和现有基础设施的性质。显然，BRMS对功能单一的小规模应用软件毫无必要。诸如ERP、CRM等大型商用企业应用软件则已经包含了业务规则，只是最终用户看不到这些规则罢了。不过，由企业自己开发的大型业务应用软件将会受益于BRMS，如果在最初设计时业务逻辑与应用软件的其余部分是隔离开的，则更会受益匪浅。
确定是否要把BRMS集成到现有的系统中是一件复杂的事情。IT部门和业务人员要协同工作，把与控制逻辑和数据验证代码混在一起的业务逻辑提取出来。在这一过程中，软件组件可能被损坏，且确定每条规则的归属可能费时又费力。此外，重构现有系统面临的另一块绊脚石是：现有规则很少是完全正确的。不一致的规则可能引发利害冲突或导致业务人员长时间讨论。最后，现有业务逻辑的每个部分都要加以检查，以确认它是否适宜于纳入新系统。
BRMS助力金融系统
金融是BRMS应用最成功的行业。例如，贷款产品的数量和品种在过去几年急剧增加，每个产品都由各自的规则集加以控制，而BRMS让业务人员变得更有创意，完全不必担心会引发过多的IT管理费用。
金融服务公司E-Loan去年放贷60亿美元，大部分是通过Jess公司提供的BRMS完成审批的，这是一个Java规则引擎。该公司使用Jess提供的源代码编写自己的BRMS用户界面，这样业务人员就可以录入简单规则，为贷款审批生成代码。
CitiStreet公司一直在寻找一套业务人员能理解的业务规则管理解决方案，结果，ILOG公司的JRules入选，因为这一产品所采用的业务操作语言（BAL）使CitiStreet的业务人员能够用既适合于本公司也适合于金融行业的通用语来表达所有规则。结果，CitiStreet业务人员平均所用的分析时间由六个月缩短到三个月。
Equifax负责产品管理的高级副总裁Lisa Fiondella说，当初她之所以采用JRules主要是因为“可以减少业务人员和编程人员之间的转换错误。”另外两个原因分别是:可以提高IT部门的整体运作效率和缩短Equifax新产品InterConnect进入市场的时间。InterConnect是基于Web的贷款审批处理和决策平台。
包括劳埃德TSB、巴克莱银行和花旗银行在内的许多大银行已经把BRMS用于各种应用中，诸如贷款资格审查和贷款计息。其中一些银行所采用的JRules软件不仅可以调查申请者的信贷历史、收入及其他资料，还可以核查共同申请人的情况，然后在此基础上可能建议申请者申请资信等级更高的贷款。当申请被批准后，BRMS就会根据贷款和销售部门制定的规则为贷款确定最合理的利息。所有这些活动都可以随时接受销售人员的监控。
选择适当的BRMS
BRMS 工具种类繁多，从开放源码系统到功能齐全的企业系统，应有尽有。如果您只是想尝试一下BRMS，您可以先用免费下载的Jess；如果是那些需要多方参与交流合作的大项目，则最好采用各项功能齐全的BRMS。
ILOG的JRules（Java版本）和Rules（C/C++版本）以及Fair
Isaac的Blaze Advisor等企业级BRMS产品附带了必要的调试、测试和分析工具，适合于那些着眼于业务整体优化的公司；而那些强调运行速度且宁愿忍受工具功能有限的企业客户最好还是考虑OPSJ。
业务规则语言并不是一种新技术，因此可能有很多IT开发人员对它都有所了解，因此，如果企业IT部门的员工以前已经接受过OPS或CLIPS方面的培训，那么不妨考虑Haley的Authorete、PST的CLIPS/R2，或者桑迪亚国家实验室的Jess。当然，新的工具也在不断出现，例如PegaSystems刚推出的新产品PegaRules，以及为规则录入提供电子表格界面的BRMS新产品Corticon。
业务人员有了JRules或Blaze
Advisor这些功能比较完善的产品后，修改规则就变得很简单了，但仍然需要业务规则逻辑方面的专家，以确保BRMS运行顺畅。据Gartner称，BRMS得到合理实施和支持后，IT人员就有望把运营成本减少10%～15%。除此之外，BRMS还会带来很多无形的好处，比如能够对不断变化的业务需求迅速做出反应，虽然这个好处很难量化，但在大多数情况下，获得回报几乎是必然的。
业务规则样本
这里显示的是一个电子商务网站的某条业务规则样本，它以“伪码”编写，很像英语的语法。
如果我们有一辆购物车
并且购物车里面至少有两件物品
并且购物车里面的物品不超过四件
并且如果购物车里面的商品价值至少是100美元
并且如果客户是黄金客户
那么就为该客户打八五折
并且显示信息“我们为您黄金客户打了八五折”
否则如果价值不到100美元，就显示信息“您想购足100美元，以便打八五折吗？”
附表：谁在制订规则？
·链接·
新标准为BRMS打开门户
在基于规则的系统出现的早期阶段，参与厂商只有寥寥几家，它们所采用的开发语言大多是OPS的某个变种，各厂商针对不同的用户需求对OPS进行一定的修改以适应特定需求。然而，无论是过去还是现在，企业都需要有一种方法能够以独立于引擎的格式录入规则。
标准的出现有望让业务人员能够使用单一、可移植的规则语法，为不同项目部署不同的规则引擎。目前由标准化组织拟议的标准包括以下一些：其一是业务规则标记语言（BRML），它基于XML格式并以独立于引擎的方式表达规则；其二是美国国防部高级研究计划署代理标记语言（DAML），它也基于XML，其主要目的是让开发人员能够标记信息页，以便让BRMS产品来读取这些信息，然后解析信息并将它们用于基于规则的上下文中。
业务规则已引起广泛的注意，这从规则标记语言（RuleML）的发展中可见一斑。RuleML最早在2000年8月的第六届泛太平洋人工智能国际会议上提出，旨在支持构建规则的两种方法：正向链接（自上而下）和反向链接（自下而上）。最初RuleML是作为一项XML标准提出的，但后来其应用范围扩大到整个基于Java的规则引擎。
金融产品标记语言（FpML）有望成为互换信贷、衍生工具和结构化产品的XML标准，而“商业产品管理计划”（Business
Products Management
Initiative）打算对覆盖多个应用系统、企业部门和业务合作伙伴的业务流程进行统一管理。
事实上，真正参与业务规则标准制定的重量级公司是Sun，它已推出了94号Java规范请求（JSR-94），并将它纳入Sun的JDK之中，虽然目前javax.rule
API能针对几种界面的类库和异常类，但它有望继续发展，成为最主流的Java规则引擎。
（计算机世界报 第33期 B7、B8）
 |
