通常情况下，BRMS会围绕一个BOM（Business Object Model）来构建规则。在设计时，这个BOM会被解释，用于编写规则；在运行时，这个BOM被实例化为一组对象（有多种实现，如Java、Schema实例等），所谓业务规则，其主要内容就是通过一些逻辑（算法）来修改对象的状态。

这个想法没有错。可是，在贷款软件开发中BRMS的目标是使这些规则展现出自然语言的特征。为了展现出自然语言的特征，BOM的属性和操作就必须被赋予一些有业务含义的词汇。使用者通过组织词汇定义出有业务含义的语句，BRMS完成这些语句与程序实现之间的映射。 

例如：如果贷款人的信用记录是良好 那么贷款额度增加50% 为了提供组织语句的功能，通常需要一套脚本（我也见过直接映射到代码实现的做法，但是脚本有利于支持更加复杂的映射，例如，虚拟函数、规则流、调试机制等），于是，BRMS需要一个规则引擎来解释脚本化的规则。在运行期，规则引擎会把脚本与底层的实现关联起来，从而实现期望的运行结果。现在需要一个开发环境来编写这些具有业务含义的规则了。通过BRMS开发环境，我们可以结构化这些规则，可以绘制规则流程图，可以调试规则，可以对规则进行版本化管理，可以定义业务词汇，可以组织语句，可以把规则发布，等等。

此外，我们可能还需要一个Web Console来进行规则的团队化开发。通过Web Con-sole，我们可以定义规则的访问权限、可以发布规则、可以与开发环境中的项目进行同步，等等。 

也许还不够。贷款软件开发过程中我们可能还需要一个运行规则的服务器（包含规则引擎），来集成到各种不同的环境（Java EE Server或者其他Server）。最后，为了完成以上的各种工作，我们可能需要指定一些专业化的角色。不同的角色将担当规则开发过程中的不同工作。 

值得注意的是，在贷款软件开发过程费用和时间是相对可控制的，降低软件开发成本必须由经验丰富的程序员来完成，并完成最终的发布。这是为了保证业务规则不会带来破坏性的后果。BRMS的问题 第一个问题是，几乎所有的BRMS都宣称，在规则发布的最后阶段技术人员仍然要充当规则验证的角色。这无疑使业务人员直接参与系统实现的期望大打折扣，同时，也使先前的市场宣传听上去像个谎言。在没有使用BRMS的项目中，技术人员被要求理解并实现客户的业务逻辑。