引言
业务规则，通常被人们描述为业务逻辑的外部化或业务自动化，是一种实现和强制实施业务策略的方法；而业务规则管理系统（BRMS ）则是加速变更过程的方法。在我作为业务规则架构师的经验中，帮助确定业务规则一直是最具挑战性的任务之一，因为业务规则一向难于理解。但是，如果理解了业务规则是如何构成的，则理解业务规则也不是那么困难。本文通过研究一个来自保险行业的实际示例，尝试揭开能将结构化逻辑分类成为业务规则的秘密。业务规则管理是总体业务流程管理（business process management，BPM）框架的一个组成部分。IBM® WebSphere® Process Server 的设计目标就是成为一个完全的 BPM 解决方案，并且业务规则也是其中的一个主要部分。本文还将提供了对 WebSphere Process Server 中业务规则组件的简要介绍。
业务条件示例
那么业务规则是什么呢？用最简单的话来说，业务规则是与特定行业中的特定业务功能有关的决策逻辑的表示形式。就业务和法律规章而言，保险行业是一个受到高度管制的行业，不遵守这些规章会付出相当惨重的代价。这些限制为该行业带来了必须采用更好的方法来管理其决策逻辑的需要，同时还使保险行业成为业务规则技术的早期采用者之一。为了介绍业务规则及其相对于过程代码的一些优点，本文将查看几个来自保险行业的业务条件示例，并讨论为什么可以更好地将这些业务条件定义为业务规则管理系统中的业务规则。
示例 1：淘汰条件
在保险行业中，保险单处理时间是最重要的，系统应用程序的更快响应可以为保险经纪人提供更多的机会以产生更多的业务。保险行业的保险单承保人使用潜在客户的驾驶记录作为确定风险的因素之一。这第一个示例演示了基于驾驶员的驾驶记录来接受或拒绝投保申请的前端承保筛选条件。
清单 1 显示了如何用简单的英语来陈述该条件。
清单 1. 用于筛选保险单申请的淘汰条件
If a vehicle is registered in California and Driver had 3 accidents in past 2 years Then Decline to underwrite or issue an Auto policy.
示例 2：分层放置条件
在提交某个保险单以后，通常会基于不同的申请条件将其分类到不同的层中。这有助于承保人确定异常的保险单申请。下一个示例演示了一个这样的分类。
清单 2 显示了用简单英语陈述的业务条件。
清单 2. 承保分层放置条件
If the age of the Driver of vehicle is between 25 and 35 And If no accidents in past 2 years Then Put this Driver in Preferred Tier. (higher discounts by default for this Tier).
示例 3：验证/资格条件
索赔处理是保险业的另一项重要职能，下面的示例定义了两个业务决策或操作，如果未在一定时间期限内提交索赔申请，则照此决策或操作执行。
清单 3 显示了用简单英语陈述的索赔业务条件。
清单 3. 保险业中的索赔处理业务条件
If Claim for an accident is not submitted within 15 days Then Do not settle the claim And Send to manual resolution queue.
上述三个示例分别演示了什么业务可解释为承保某个保单、基于驾驶记录给予折扣和解决索赔所必需的条件或约束。保险行业的全部意义就是管理和最小化风险。为实现此目的，保险行业使用软件应用程序来系统表达业务条件并自动化这些条件，这正是 IT 专家派上用场的地方。在引入 BRMS 以前，IT 完全控制着业务规则的管理，使得事情从最终用户的角度看来非常困难。这样还为造成误解留下了巨大的空间，从而产生管理不善的代码，并最终影响总体业务。而且 IT 使用某种编程语言来实现业务规则。清单 4 显示了使用诸如 Java™ 等面向对象的编程语言将淘汰条件（来自 清单 1）编写为结构化逻辑时的代码。
清单 4. 使用 Java 语言实现的淘汰条件
public String driverKnockOutCheck(Driver driver) {
// The first step is to call another method to calculate the total number
// of accidents in past x number of years.
int numOfAccidents =
calculateNumOfAccidentsInPastNumberOfYears(2);
// Apply the business logic and based on this set the status of
// policy to APPROVED/DECLINED.
If (numOfAccidents >= 3) {
currentPolicyStatus = DECLINED;
}
return currentPolicyStatus;
}
这个实现并没有什么错误，虽然要更改或管理它不是那么容易。业务还必须寻求来自 IT 的帮助来实现任何修改。下面是从业务用户的角度来看，这种方法的一些缺点：
- 硬编码的逻辑——可以注意到，诸如年数、允许的事故数量和各种常量等所有参数都硬编码在代码中。一旦将此代码编译为可执行代码，要对其做出更改将非常困难。
- 特定于语言的编码——如该示例所示，当使用任何编程语言实现这样一个条件时，需要了解该语言的专家/程序员才能对业务约束进行任何类型的更改或更新。
- 实现更改所花的时间更长——即使更改单个属性也必须经历软件开发生命周期的大多数步骤，有时可能要花数周甚至数月的时间。例如，假设业务分析人员决定允许 5 次事故而不是 3 次。要做出这个简单的更改，必须经历大多数软件开发生命周期步骤，例如开发、QA 和发布管理。
- 业务无法拥有直接的控制——最重要的是，业务无法拥有对该逻辑的直接控制，而是必须依赖 IT 来做出任何更改。
可以采用各种各样的方法来自动化变更过程，并为业务用户提供对这些变更最大限度的控制。其中一种方法是将逻辑定义为 BRMS 中的业务规则。下一个部分将探索如何将结构化的逻辑定义为业务规则。
业务规则是什么？
在 Internet 上搜索“业务规则”可以找到许多不同的定义。下面是较常见的定义之一：“业务规则是对业务的某些方面进行定义和约束的声明”。很简单，不是吗？业务规则一般包含一组声明性的语句和约束，然后这些语句和约束可以断言某些操作或目标。简而言之，业务规则是关于业务操作是“什么”而不是业务操作该“如何”。业务规则的主要目的是断言业务结构，或者控制或影响业务的行为。因而，规则包含某个“用户需求”的正式和可实现的表达，通常使用自然语言（例如英语）以文本形式进行陈述。
该文本形式称为业务规则语句。每个业务规则语句表示在运行业务当中，一个离散、可操作的实践或策略，而与任何特定的实现手段或特定的技术无关。（当然，规则的实际强制方式一般不应该牵涉到用户。）
本文开头讨论的淘汰条件规则实际上就是一个业务规则，因为它是在强制一个业务约束——拒绝高风险驾驶员的保险单。
另一个淘汰条件
让我们看一下另一个示例，此示例说明了一个基于驾驶员的驾驶记录来接受或拒绝保单申请的承保筛选条件。用简单英语陈述的该条件如清单 5 所示。
清单 5. 筛选保单申请的淘汰条件
If a vehicle is registered in California and Driver had 3 accidents in past 2 years Then Decline to underwrite or issue an Auto policy.
此示例以及上述的所有其他示例都是业务规则的例子。当使用良好的 BRMS 来实现时，可以使用简单的英语短语来编写这些规则，就像清单 1中的淘汰条件示例所示的例子一样。这种类型的熟悉性使得业务策略制定者可以与 IT 紧密配合工作。值得重复的是：BRMS 工具允许业务用户使用简单的英语来定义规则。此功能本身就是使业务转向使用 BRMS 系统的最大诱因，因为它给最终用户提供了无需学习复杂的编程语言即可控制业务逻辑的强大能力。下一个部分将探索一些其他功能和使用 BRMS 工具的理由。
BRMS 是什么以及它提供什么功能？
BRMS 是用于创建、管理和支持企业的业务规则的软件工具。它们通过为业务分析人员提供对业务逻辑的控制，从而在业务和 IT 之间架起一座桥梁。其基本思想在于，BRMS 将应用程序的业务逻辑与其数据验证逻辑和流程控制分离开来。业务逻辑在自己的容器（即“规则引擎”）中运行，业务分析人员使用简单的英语式的编程语言编写业务规则代码，该代码非常容易理解和学习。即使是从来没有使用任何编程语言来编写过程序的业务用户也能够轻松创建和管理这些规则。
图 1 显示了BRMS 系统概念上的通用体系结构。
图 1. BRMS 系统体系结构
任何一流的 BRMS 系统都具有三个主要组成部分。第一个部分是 IDE，即集成开发环境（Integrated Development Environment），由 IT 人员（主要是规则开发人员）用于创建必需的框架，以便创建业务和管理规则。第二个部分是规则管理应用程序（Rule Management Application），这是业务用户用于创建和更改规则的用户界面。最后一个部分是规则引擎（Rules Engine）本身。业务应用程序/系统与规则引擎连接，以基于规则存储库中创建的规则来获取自动化的决策，其中规则存储库充当规则数据库。
下面是一些可从 BRMS 体系结构中明显看出的优点，如图 1 所示。
- 对于管理企业应用程序的必需行为方式的规则，业务用户拥有直接的控制。
- 几乎无需与 IT 交互即可修改业务逻辑。
- 由于规则是使用简单的英语式语言编写的，业务级别的人员更容易理解规则，从而改善业务与 IT 之间的关系，缩短实现时间，以及减少发生解释错误的机会。
- BRMS 还提供了不同的方法，可以对规则进行分组以便于理解和管理。这样的一个规则分组称为一个规则集（RuleSet）。规则集是逻辑上具有共同之处的规则的集合。
- BRMS 工具促进了松散耦合的体系结构。诸如 Blaze Advisor 和 Pega Rules 等一流 BRMS 还支持面向服务的体系结构（Service-Oriented Architecture，SOA）。
- BRMS 提供了丰富的开发、测试和文档功能，例如：调试、受控的执行流、交叉引用工具和报告工具。
- 更好的规则管理——当您有大量的规则需要实现时，BRMS 是更好的选择，因为它能够简化所有那些规则的管理和组织。跟踪、记录和调试问题也更加容易，即使是在规则总数非常大的情况下。
使用 BRMS 的附加优点
由于 BRMS 中的规则是作为一个独立流程进行管理和执行的，因此可以将其嵌入应用程序中或由应用程序调用，并且无需重新编译即可在任何时候更新规则。只要实现方式得当，甚至可以在不对生产系统产生流程中断的情况下做出更改。可以对更新后的规则进行离线测试，然后按照部署策略（定期发布周期、快速发布更新等等）逐步将其引入运行的应用程序。
有关一些领先的 BRMS 产品提供商的列表，请参见本文的参考资料部分。
IBM 在 BRMS 领域的倡导工作——WebSphere Process Server
由于从本文开头起一直在指出的诸多原因，保险行业一直在努力摆脱其遗留系统：过程代码非常难于维护，而遗留系统中使用诸如 COBOL 等语言编写的代码则更加难于维护。IBM 一直在积极协助和支持从遗留系统迁移到更成熟的系统的工作，这些更成熟的系统包含诸如 Java 等面向对象的语言，同时还包含诸如 SOA 等耦合得更松散的体系结构。WebSphere Process Server 就是 IBM 推出的一个这样的倡导工作，以帮助包括保险业在内的所有行业完成迁移工作。
通过使用 WebSphere Process Server 来处理包括业务流程管理 (BRMS) 在内的更大技术组件，IBM 正在采取一种独特方法来实现业务规则。WebSphere Process Server 的设计目标是成为一个完全的业务流程管理（Business Process Management，BPM）解决方案，并且业务规则是其中的一个主要部分。从技术角度看，WebSphere Process Server 是业务驱动的开发流程中产生的构件的运行时引擎。WebSphere Process Server 被宣称是下一代的业务流程服务器，并支持基于 SOA 和开放标准的不同形式的集成。基于服务的模型支持跨人员、工作流、应用程序、系统、平台和体系结构的业务流程的自动化。图 2 给出了 WebSphere Process Server 平台的概况。
图 2. WebSphere Process Server 平台和作为其主要服务组件之一的“业务规则”组件
图片来自标题为“WebSphere Process Server：IBM 为 SOA 提供的新基础”的 IBM developersWorks 文章。
WebSphere Process Server 中的业务规则编写功能由一个基于 Eclipse 的桌面工具提供支持。业务分析人员可以使用该服务器附带的基于 Web 的运行时工具。该工具还独立于服务器中的其他服务组件，从而允许动态编写规则而不会影响其他服务。这是一个功能强大的 BRMS 工具。
总结
业务规则并不是一个新思想。自从最初在软件应用程序中引入人工智能以来，业务规则就已经存在了。但在传统上，业务规则是在过程逻辑中实现的，并深埋在应用程序中。此类实现的最大问题在于，它们使得规则的强制实施变得高度不一致，并使得对规则的快速更改几乎无法实现。我们需要某种完善和成熟的工具来减轻此类问题。BRMS 就是这样一种充满前景的技术。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
