对象模型优先

制定决策时你一般从什么地方入手?你是否上传了一个预定义的对象模型?或者是用决策逻辑来开发它?

对象模型优先

根据我们的经验,在绝大多数的项目中,对象模型是已经存在,IT部门定义并维护的。这非常合理,因为对象模型其实是决策服务在技术上和其他系统交互的一种约定。在执行决策服务应用前,我们需要知道的全部功能。而调用系统也需要知道如何找到决策及其相关参数。

对象模型,或数据模型,亦或数据模式,实际上定义了与决策服务进行交互的数据结构。其中有一些区块(section)和字段(field)是输入数据,另有一些是输出数据。业务规则将直接定或是通过计算得出这数据

在我们Sparkling Logic的体系里,我们将这些对象模型称为表单(form)。当你把某个申请视为数据时,表单就代表了该申请的数据结构,其中明确了每部分数据的含义。例如,“客户信息”是一个区块,包含了“姓名出生日期”等字段。

尽管数据字段是业务规则的基础,但是字段的定义通常还是由调用系统来定义的。调用系统将产生交易消息(又为交易数据),并在规则执行完成并做出最终决策后收回反馈消息

总而言之,对象模型是由IT部门所有的,因为他们负责实际的决策服务调用

修改对象模型

那这是否意味着,业务部无法修改对象模型当然不是。通常我们希望通过计算和统计来丰富对象模型。“客户信息”可能会包含客户生日,但是业务规则可能是参考客户年龄制定的。那么通常的做法是增加一个“年龄”字段,用简单的公就能计算出来。可以用类似的方式来添加更多的字段,以实现对更多数据的计算和统计,如共同借款人的总收入,或者计算债务收入比等。

在大部分系统中,这些计算字段决策服务来说是不可见的,因此IT部门甚至都不知道这些字段的存在。

另一种非常类似的机制,就是向表单中添加业务术语business term)作为表单中业务概念的一种补充,业务术语构成了可以在项目之间共享的额外用语。例如,你可能想要一劳永逸地定义“老年人”这一概念的划分边界,而通过业务术语,甚至可以对每个分别明确其边界。业务规则无需重复定义这些条件可以直接引用这些业务术语,比如:如果申请人是“老年人”并且他的家庭状况是“单身”,这里“老年人”和“单身”就是我们定义的两个业务术语。每一个引用了该表单的项目,都可以重用相同的术语,而不需要一遍又一遍地去定义它。

和计算字段类似,业务规则可以直接使用业务术语,而IT部门不会看到这些术语的。

除了计算字段和业务术语,最终我们或许创建新的变量。没关系,引入中间变量以简化业务规则不会带来任何问题。尽管这些字段对于IT来讲是可见的,但是他们无需理会。作为中间变量,调用系统甚至可以不在数据库中保存这些值。

何时提供对象模型?

理想的做法是基于已经建立的对象模型来启动决策管理项目。上传数据建立数据结构,无疑是项目实施的第一步。不论你是否已经有实际的历史数据,还是为了规则的单元测试构建数据样本,这都是毋庸置疑的。

坦白讲,在具体编写规则之前建立好对象模型的原因是非常简单的。因为每次修改对象模型,那些依赖于对象模型(在我们的案例中是表单)中受影响部分的规则需要

当然,某些修改可能对规则没有影响。如果是这种情况,那自然可以简单愉快地拓展对象模型。

有些修改只是在表单内部移动区块和字段。只要受影响字段的类型保持不变,规则一般就无需重写。唯一的例外就是,规则在引用字段时不是使用了简写,而是使用了完整路径。例如,如果你的规则写的是‘年龄’ < 21”,那么‘年龄’这个字段不论在哪里都是可以的;如果规则写的是‘客户’.‘年龄’ < 21”,那么‘年龄’字段被移到了其他区块下,就需要对其进行修改。

最后,有一些修改可能是影响相当的。比如,在原先的保险政策中,一个保险申请只允许投保一个驾驶员,现在变成了一个保险申请允许投保多个驾驶员,保险申请与驾驶员数据从一对一变成了一对多。那么针对驾驶员的审核规则将必须考虑结构上的改变。你就必须要定义,年龄规则是适用于所有的驾驶员,还是任意一个驾驶员,亦或者是主要驾驶员。这就是规则重构可能带来的麻烦

对象模型越稳定,就越适合编写规则。

这里我还想强调一件重要的事情,就是IT团队和业务分析团队需要充分沟通,并且在对象模型的字段使用达成一致,要保证:

· 字段取值是明确地记录在文档中,并且都认可的:例如,使用缩写CA还是全称California

· 明确地知道具体哪些字段是输入字段:如果“州”这个字段出现在了多个地址中,知道哪个是优先级更高的

抱歉稍微有点离题,但这的确是我们看到的,“规则修复”工作中最占精力的地方

何时由规则决定对象模型?

这很少见但也确实会发生。我们大多是在一些新兴领域的项目中看到。这时候没有业务记录数据库,也没有现成的基础结构,对这些新项目来讲预先定义好自己的对象模型是一种奢求此时可行的选项也就只有:让数据建模人员来定义对象模型,或者随着业务规则的提炼来提取完善对象模型。

在这些案例中,我们往往看到DMN(decision modeling and notation,决策建模与标记法)标准的权衡利用。当业务分析人员使用类似慧笔https://www.sparklinglogic.com/pencil-decision-modeler/)这样的工具提炼源规则时,规则所用的词汇表也就得到了整合

考虑到有不熟悉DMN的朋友,我这里概述一下这种方法。决策模型表示法可以通过分解决策逻辑,来指导业务分析人员。比如,你需要计算车险的保费,就需要确定基本费率和附加费率。确定基本费率,你需要知道驾驶员的详细信息:年龄,风险等级和地址;你还需要知道车辆的详细信息:品牌,型号和年份。作为业务分析人员,需要深入到决策的各层次,直到完整获取了所有相关规则。

而词汇表就是你在此过程中遇到的所有属性的集合,如驾驶员的年龄风险等级地址车辆的品牌型号年份,等等。这个过程中也会定义输入和输出属性。你也可以将这些属性组织到不同的类别中。当你完成了这些工作后,词汇表就可以被转化为一个表单,各个类别相当于表单的区块,各个属性相当于表单的字段。通过这种方法,你在完成决策逻辑制定的同时获得了对象模型。

最后总结下

除了类似计算和中间变量的少量添加外,体而言对象模型从一开始就IT部门所有并提供的。只有在新兴领域的项目中,才可能将规则和数据模型的获取结合。

产品
解决方案
学习
上海杨浦区昆明路739号文通大厦9F
©2021 上海数泱信息科技有限公司 版权所有