BRMS: 连通业务与IT - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

企业的业务规则对绝大多数人来说都非常抽象，就算是企业的决策者也说不清自己的企业内部到底有多少业务规则在使用。如何让企业规则与企业的数据信息一样成为企业的重要资产？
业务规则管理“复苏”
规则和逻辑是人工智能理论中最基本的概念。比如机器人在遇到前方障碍物的时候，系统就会自动触发某种应对规则，告诉机器人绕开障碍物继续向前。通过规则的逻辑运算，还可以赋予机器人简单的推理能力。当这些规则和逻辑在一个机器人中出现的时候，我们似乎习以为常。但如果把规则用于商业应用系统又会产生什么样的效果？
其实，在一个企业实体中同样存在着各种各样的规则，像管理制度、业务手册、工艺流程、操作规范、收费标准、促销策略等都是规则，甚至一些没有形成文字的惯例，也是企业规则的一部分。因为是与业务相关，所以又称它们为业务规则。
业务规则分散在企业的各个角落，就算企业的决策者也很难说清楚自己的企业内部到底有多少业务规则在使用。大部分的业务规则存在于业务人员的大脑中，或是为数不多的工作手册、操作规范等非结构化的文档上。作为描述企业最重要特征的业务逻辑没有被有效地管理和使用，导致好的经验无法积累，差的经验无法总结。即使企业使用了计算机系统，业务处理逻辑也总是被看成一个个过程写进了程序代码中，当某些需求和业务规则发生变化时，必须修改原有代码，修改和维护的成本都相当高。
业务规则管理（Business Rules Management，简称BRM）技术的出现彻底改变了以过程形式处理业务逻辑的方式，它将业务规则的实现从具体的程序代码中抽取出来，以结构化的业务规则数据来表示企业的业务行为，使得业务规则与企业的数据信息一样成为企业的重要资产。与此同时，软件开发的习惯也开始因BRM而改变。业务规则像数据一样独立于程序之外，业务人员可以使用行业术语而不是专业编程语言来编写规则，从而使企业的业务系统真正面向业务人员。
在20世纪80年代，基于规则的编程方法曾经随着人工智能的研究热潮达到顶峰，但因为当时规则引擎性能很差，并且没有与当时主流应用系统的集成能力，所以没有得到很好的应用。不过现如今，商用业务规则引擎的性能和稳定性都已经达到相当高的水平。按照Gartner 的观点，业务规则技术正从前一次的“垂死经历”迈向复苏。
对于一个以追求利润为使命的企业组织来说，规则对其使命的完成起着关键作用。一个组织的成功取决于及时有效的决策能力，而这种决策能力最终要变成策略及规则去落实执行。
策略和规则总是在不断变化，但一旦把业务规则像数据一样从程序中剥离，业务规则易变的难题也就迎刃而解，其中理念改变在于“用管理数据的方式来管理业务规则”。在说到业务流程管理（Business Process Management，简称BPM）的时候，我们也曾经提到要以管理数据的方式来管理业务流程，虽然与BRM的工作原理有些类似，但二者关注的层面不同，业务流程关注的是对企业内部独立系统和实体的整合，商用BPM产品大多把规则引擎嵌入在BPM引擎之中。
从本质上来说，业务规则并不是新鲜事物。GUIDE Business Rule Project对业务规则的定义是：“业务规则是描述和约束业务的语句，用来刻画业务的结构或控制和影响业务的行为。”业务规则具有如下特性:申明性、准确性、原子性、一致性、非冗余性。
业务规则方法学提供了一种依照业务规则概念进行分析问题和解决问题的方式，帮助人们发现规则、表现规则、管理规则、自动执行规则，建立规则运行机制，最终目的是实现业务规则管理系统（Business Rule Management System，简称BRMS）。使得简单的非技术性的概念容易被技术人员和业务人员所理解，业务人员不必涉及数据模型、处理模型和对象模型即可直接面对业务规则，同时更加深入地参与系统的需求分析、设计与实现。
业务规则存储在规则库中，完全独立于数据和程序。业务人员可以对业务规则进行查询、添加、更新、统计、提交等操作，并且可以在线修改和测试业务规则。业务规则可以不断积累、调整和共享，并能对规则进行版本管理，设定规则的有效期，实现对业务行为的知识管理。系统的稳定性也因此得到了保障，系统的维护成本大大降低。
分层和复用是当今软件开发的两大技术方向。分层技术解决了系统的复杂性问题，降低了系统内的耦合性;复用技术解决了开发的效率和可靠性。业务规则管理技术恰恰与这两大技术的特点相吻合，综合体现了分层和复用所带来的好处，并且很好地融合了数据库技术和面向对象技术的优势。
智能化是业务规则管理的另一大特点。业务规则最主要的能力是行为约束和知识推理，规则引擎可以进行逻辑判断，建立数据对象和规则之间的映射关系，并且能够动态组织与该数据对象相关联的、满足条件的业务规则，自动实现这些规则之间的一致性、时间顺序、相容等逻辑关系，可以推导出新的业务规则。随着规则引擎技术的进一步提升，它的智能化特征将在知识管理、决策支持、BI等领域具有非常好的应用前景。
其实，现在基于业务规则的应用系统越来越多。例如前面提到的业务流程管理系统，不少BPM都内嵌了BRM引擎；使用业务规则技术对遗留系统进行改造，去掉系统中易变的业务逻辑处理程序，放置一个规则引擎，可大大减少系统的改造费用，增强系统的可维护性;在客户关系管理系统中，可使用以事件驱动为特征的规则引擎，实时定制工作流程和业务处理;此外，业务规则管理技术也可以用于在线分析处理、数据仓库、现代物流等应用中。
在一些个性化需求较强的应用中，为每个客户编写个性化的处理程序是不可能的，但为每个客户建立相应的业务规则是可能的。利用业务规则管理技术，可以在不修改应用程序代码的情况下，为客户提供个性化的服务。目前电信、金融、保险等行业已经有不少软件开发商和用户使用业务规则管理技术。
不过值得一提的是，目前还没有对业务规则的工业标准化定义，多种业务规则描述语言并存，各种规则引擎对这些规则语言的解释与执行也不兼容，这在某种程度上妨碍了业务规则技术的发展。此外，虽然市场上已经出现了不少规则引擎，但只有为数不多的引擎达到了实用性能（每秒触发上万次规则的执行）。
固化在程序代码中的策略和规则必然是僵硬的。客户的多态性和市场的多变性决定了业务规则和策略的变化必然很频繁，如果规则的每次改变都要求对系统程序进行“伤筋动骨”式的修改，那么系统的维护和升级必然代价昂贵，甚至难以维持。
● 业务规则的“逻辑性”
业务规则具有逻辑性，每条约束行为的业务规则至少包含两个部分：条件部分和执行部分；规则的条件涉及到对业务数据作用的判定，规则的执行涉及到对业务数据的处理。所以规则不是简单的业务数据。
● 业务规则的“非过程性”
每条规则只能定义对一种现象的判断和操作，复杂的业务逻辑应该由多条规则协同处理。规则的“非过程性”带来的好处是：每条规则的制定变得非常单纯，可以“就事论事”，将复杂的过程处理平摊成一个个有条件的执行单元，实现了从简单到复杂的知识积累过程。
● 业务规则的“事件触发性”
业务规则会根据相应的条件被触发执行，触发规则执行的“事件”就是业务数据本身。比如一套信用分析的规则集合，一旦客户信用记录信息进入系统处理，这组规则将会被激活，并启动相应的分析过程。
● 业务规则的“非技术性”
业务规则是属于业务人员的，业务人员应该使用行业语言而不是专业技术语言（如程序语言、数据库语言、脚本语言等）编写规则。
Business Rule的另外一个名字就是Workflow. Oracle里有集成，开源的workflow引擎也有几个，比如www.jbpm.org
唉，东西虽好，可惜暂时没时间研究，以后再看看巴。
嗯，你说得对，business rule和business process还是有区别的。不过区别也比较模糊，看了一下介绍jrules也支持workflow管理的。。。这个领域好像还没什么统一的定义，标准。
感觉在更高抽象层次上，更面向用户的设计反而从面向对象转到面向过程了，真是奇妙。
业务规则和工作流区别太明显了，早期的系统是把两者混在一起，现在的设计思路是必须把两者明显的区分。
工作流是描述业务的具体流向，是线性的
业务规则是一个个的条例，是需要工作流把规则给串行起来才起作用的，也就是说业务规则是一个个的点