业务规则挖掘最佳实践

业务规则挖掘最佳实践

以下是关于技术规则的语义捕获及其抽象成业务规则的通用方法。

准备步骤

一系列准备工作有助于避免冗长的规则挖掘过程，确保规则对业务有价值，并加快创建“业务”规则而非仅仅“技术”规则的过程。建议采取这些步骤以建立正确的组织框架，并使规则挖掘与业务优先级相一致。

1. 项目目标和预期输出

定义规则挖掘活动的目標和输出非常重要。这将根据组织的业务优先级而有所不同。对于一些组织而言，目标可能是解决高度价值且定制化应用的灵活性不足或高停机时间问题。这可能导致将应用迁移到支持 SOA 的打包应用程序的决策。

根据目标，规则挖掘活动可以产生两种主要结果。

文档在某些情况下，目标可能是开发面向业务的程序代码段文档。这种文档对其他分析师和主题专家而言是宝贵的参考，也可以用作现代化、待开发应用程序的高级设计模型的装饰。它通常不会生成可执行的业务规则，也不会成为开发环境的输入。

业务规则在其他情况下，需要将应用程序中编辑和计算的确切语义行为捕获为真正的业务规则。捕获的语义将用作目标开发环境的基础，甚至直接输入到目标开发环境。此步骤的结果将驱动有关技术采用、资源规划以及应用于两种规则挖掘类型最佳方法的决策。

2. 规则挖掘技术选择

主要采用手动方法规则挖掘技术的低成本、低价值应用是在文字处理或电子表格应用程序中记录规则。这种方法不能帮助解决规则挖掘中最耗费资源的部分，例如分析应用程序行为并在源代码段中定位规则。

运行时模拟帮助将用户行为捕获到流程和规则中的运行时模拟技术，可以从行为方面提供帮助。其主要缺点是，它们仅限于给定时间段内实际执行的测试场景，可能遗漏通常不会执行的关键异常。

扫描工具能够在源代码中定位模式的文本扫描工具，可以加快基于源代码中固定模式的规则捕获（例如，显示对变量的所有移动）。这些工具通常会生成大量误报，并且往往导致技术规则而不是业务规则。

基于存储库的规则挖掘工具基于存储库的技术可以重新编译源代码并构建语法解析树，这可以为规则挖掘提供最高价值。最先进的工具使用语义分析自动检测规则，例如，从兴趣点变量上游的每个语句，以及可能影响其值的语句，都被挖掘为候选规则。

规则挖掘工具还可以提供规则管理和审计功能，便于项目工作流程和评审人员进行规则维护活动。它们还能够保留规则与源代码之间的可追溯性，即使源代码发生变更（在实时环境中经常发生）也是如此。

考虑到以上因素，规则挖掘的低成本方法的权衡将是更高的手动工作量和较低的结果质量。这在一线性、小规模文档场景中可能是可以接受的，但在企业级现代化工作中则不太可能如此。

3. 时间和资源分配

项目目标和技术选择将影响资源分配。在很多情况下，业务方面的期望是收到从应用程序语义中推导出的精确建模的业务规则集，而没有意识到这种努力的复杂性。在 IT 方面，没有规则挖掘经验或对应用程序主题不熟悉的从业人员无法提供可靠的估计。

可以采用迭代方法来估计时间和资源。在最初的几周内，针对应用程序的代表性子集挖掘规则，可以洞悉最适合所选应用程序的方法，以及用于估计总体工作量的标准。

4. 业务流程映射和对齐

挖掘的逻辑很重要，因为它具有业务上下文。毕竟，逻辑是更广泛的业务流程的子集。只有将挖掘的规则置于相关流程的上下文中，这些规则才有意义。例如，根据客户的邮政编码将她分配给收入范围，在信贷审批和营销活动流程中可能具有不同的意义（例如，保险公司会宣传他们只会查看过去的行为，而不是信用评级来设定保费）。

此外，在业务流程上下文中查看应用程序对于确定规则挖掘活动的优先级非常重要。企业通常从其流程的角度看待自己，例如注册新客户、承保保单、收款、注册索赔、将资金存入账户等等。其中一些流程对组织至关重要，而另一些则仅仅是商品功能。一些流程可能满足业务线主管设定的服务水平协议，而另一些则没有。现代化活动将根据这种计算来确定重点。

一旦业务流程建模完毕，就确定支持所选流程的应用程序元素。从历史上看，这些应用程序是孤立组织的，这使得高级匹配成为一个简单的步骤。然而，在更细粒度的层面上，单体订单管理应用程序可能处理客户注册、信贷审批、订单录入和订单履行。如果组织只对客户注册和订单录入组件的规则挖掘感兴趣，那么在流程及其支持的应用程序组合元素之间进行映射练习将是有益的。

借助基于存储库的软件，应用程序对象会被注册，并且会自动捕获对象之间的语法和语义关系。

记录重叠情况，即程序或数据存储服务于多个业务流程的情况。

示例 - 客户订单

在下图 1 中，客户主数据、订单主数据和库存数据存储都在规则挖掘的范围内，尽管它们支持范围之外的其他流程。类似地，客户处理程序是单体的，并且包括信贷审批的逻辑，而信贷审批超出了此范围。

图 1：业务流程映射到应用程序对象

5. 应用程序分析

在之前的步骤中，已经对应用程序进行了清单，并且在较高层面上已经了解了目标业务流程在应用程序工件中的位置。下一步将是将应用程序分解为其组成逻辑元素。一个关键因素仍然是上下文化。与组织优先级无关的应用程序元素被排除在外。这种通过上下文的范围界定使我们能够看到规则及其相关影响的“边界”。

应用程序分解

在此步骤中，应用程序将进一步分解为其详细组件。目标是获得足够详细的工件集合，以便作为规则挖掘步骤的输入。

同样，技术可以提供帮助。基于存储库的软件可以创建详细应用程序对象及其关系的解析树。然后，此信息以多种图形和文本视图呈现，这些视图彼此同步，以便于进行上下文敏感分析。

例如，上下文视图将以压缩的概述模式显示程序中的所有数据字段声明、过程和过程调用。详细的源代码视图将显示与上下文视图相对应的代码段，允许通过上下文视图快速浏览程序。通过上下文视图的遍历，用户可以快速了解程序的结构和复杂性。

其他在详细程序级别可用的视图包括段落之间控制流的图表、段落内的逻辑流程图、执行路径和针对所选条件结果的运行时模拟器。这些工具用于在实际开始规则挖掘阶段之前深入了解应用程序。

在没有自动解析工具的帮助下，仍然可以通过对应用程序工件进行手动检查和演练来获得价值。

排除项识别

在审查和分析应用程序的过程中，出于功能和技术原因，不应包含在规则挖掘范围内的元素将被标记。这些元素可能包括标准实用程序、报告、系统例程和超出范围的业务流程。在图 1 的示例中，这将包括与信用审批和订单履行相关的工件，由于其作为商品、标准化业务流程的性质，因此超出范围。

排除项的识别说明了从上述前期业务情境化步骤中获得的好处。如果这些步骤没有进行，则“全面扫描”方法会导致在规则挖掘和 SME 审查阶段投入更多，因为来自商品业务流程的规则首先会被挖掘，然后会被舍弃，因为它们是无关的。

6. 词汇表创建

从应用程序中挖掘规则的一个主要挑战是，在应用程序内部导航各种变量和命名约定可能很困难。这些约定通常与业务术语之间存在着微妙的联系，并且可能使从业务角度理解逻辑变得困难。

最佳实践是改进这些技术术语，以创建一个更以业务为中心的视图。这可以通过应用程序对象和相关业务术语的词汇表来实现。对象可以是数据字段、段落、程序、数据源以及其他感兴趣的应用程序对象。

术语词汇表的来源可以是业务文档、数据字典、数据库模式、用户通知，甚至源代码注释。

自动规则挖掘工具提供了一种机制，用于传播应用程序中重复模式（通常称为“令牌”）的值。例如，令牌“ACCT-”可以在任何地方被替换为“Account-”。然后，工具将使用词汇表业务名称来替换自动构建候选规则中的技术术语。

7. 规则组成和层次结构定义

预先确定所需的规则格式。用于设置订单折扣的相同规则可以采用不同的形式，例如

(i) 声明性形式：“每个来自加州的 AAA 高级会员都将获得 5% 的折扣。”

(ii) 如果-那么-否则形式：如果申请人是高级会员，那么如果她是 AAA 会员，那么如果她居住在加州，则分配 5% 的折扣。

(iii) 作为决策表中的条目

图 2：决策表中的条目

将其他信息和工作流属性附加到挖掘的规则可能很有用，例如

• 审阅者文本注释
• 规则类型（输入/输出、计算、验证、安全）
• 审核状态（已批准、未批准）
• 工作流状态（提取、工作、接受、拒绝）
• 转换（有效、需要修改、重复、完成）
• 审阅者身份
• 程序来源
• 代码段位置（开始、结束）
• 代码段文本
• 输入和输出数据元素

规则还将放置在层次结构中。所有代表决策或在给定条件集下执行的规则可以分组到规则集中。规则集将被分组到更高级别的活动节点，反映它们当前参与的业务流程。

如果您计划填充可执行的业务规则管理系统 (BRMS)，您将希望定义一个易于传输到所选特定目标环境的模式。如果目标环境尚未确定，请参考现有的业务规则标准。

8. 规则挖掘工作流

企业规则挖掘通常是一个多步骤过程，涉及具有不同技能集的从业人员，包括顾问、开发人员、架构师、分析师和主题专家。关键人员经常会被其他项目分散注意力，因此定义和记录通用工作流至关重要。

按照本文档中进一步提供的指南，高级工作流可能如下所示

图 3：示例规则挖掘工作流

每个步骤都应根据采用​​的方法、项目范围和约束以及规则挖掘技术的使用来详细定义。前几个步骤可能会有多次迭代，直到规则处于已批准的最终格式。

规则挖掘步骤

9. 候选规则的挖掘

此时，规则是从映射到先前步骤中确定的业务流程范围的应用程序工件中挖掘的。规则挖掘工具可帮助您确保排除的工件不包括在范围内，方法是使应用程序能够组织成子分组。将针对子分组而不是针对整个应用程序挖掘规则。

采取的具体规则挖掘方法主要由应用程序模式和期望的输出驱动。

自顶向下方法

自顶向下或面向流程的方法从在线应用程序中用户界面或批处理应用程序中作业流程的检查开始。

在在线应用程序中，用户选择菜单选项或在屏幕上输入值可以调用事务。识别定义从屏幕发送到接口应用程序的消息或事件的字段。触发消息中的每个字段都可以被视为规则挖掘的种子字段。

以种子字段作为起点，记录对该字段的所有下游数据影响，包括所有条件排列。每个数据转换（移动到另一个字段或计算）都表示要捕获的候选业务规则。

规则挖掘软件工具通过可视化每个种子字段的每个数据影响路径，直到它被新值填充或通过比较、值传播和计算用作其他字段的输入，从而帮助完成此任务。在每个这样的点，该工具可用于记录底层的业务规则。自动规则检测方法也可以应用于捕获每个屏幕字段编辑作为候选规则。

在批处理应用程序中，概念是类似的。识别作业流程的一部分，例如实现业务流程的作业控制语言或其组，并挖掘与该流程相关的单个程序中的所有规则。

图 4：自顶向下规则挖掘

在上图 4 中，请注意生成的“派生候选规则”的格式。它们是从 Cobol 程序中自动检测到的，类似于它的构造，变量名称被词汇表定义替换。这些规则将在以后进行审查，并转换为更符合业务的格式。虽然此示例是针对 Cobol 应用程序展示的，但高级挖掘工具可以应用于从 PL/ 和 Natural 到 Visual Basic 和 Java 的广泛语言。

自底向上方法

自底向上或面向数据的方法从检查系统输出开始 - 发送到文件（批处理和在线）、屏幕和输出消息（仅限在线）的数据。

遵循这种方法，规则的捕获是通过从一个有趣的数据点开始，识别影响该点的所有逻辑来实现的。例如，订单折扣字段受从其上游计算的折扣的影响，具体取决于客户的居住地。

图 5：自底向上规则挖掘

规则挖掘技术特别适合这种方法。通过视觉检查或存储库查询，可以快速识别出感兴趣的数据输出。然后，自动规则检测例程能够为影响感兴趣点的每个语句捕获候选规则。由于先前已组织到上述情境化子分组中，因此搜索结果将受到被认为与规则挖掘相关的业务流程子集的限制。

检查相关的 DBMS 表也可能生成嵌入在键中的规则，以及用于参照完整性和值约束的任何数据规则。一旦涵盖了所有感兴趣的数据点，面向现有输出的所有感兴趣的应用程序逻辑基本上就已经挖掘完毕。

混合方法

混合方法结合了上述两种方法

• 第一步是自顶向下捕获相关事务；
• 对于每个事务，执行自底向上的规则挖掘，仅包括尚未为其他事务挖掘的数据输出。

这种方法的好处是扩展了规则挖掘的覆盖范围，同时避免了重复。

与上图 4 和 5 中所示的示例相关，严格遵循自顶向下的方法会导致对数量和价格字段的重复工作，因为它们都遍历了相同的下游数据影响。覆盖范围也不完整，因为没有发现客户折扣的所有规则。

让我们考虑一个涉及订单输入和提案签发流程的扩展案例。采用排他的自底向上方法也会导致重复，挖掘针对多个输出（例如客户折扣规则）“命中”的上游数据影响的规则。使用混合方法，我们将首先从所有订单事务输出中挖掘规则，然后只从特定于提案事务的输出中挖掘规则。

图 6：混合规则挖掘

10. 候选规则验证

此时，在从应用程序中挖掘出候选规则后，验证和更正是确保规则的正确性和完整性的必要步骤。

检查候选规则以确保

准确性 每条规则是否正确反映了底层应用程序行为？如果使用了自动规则检测技术，则在感兴趣点（种子字段）处的规则将先于来自其上游的规则，可能带有触发器、控制条件和自动规则集分组。对它们中的每一个（或选定的子集）进行准确性审查，并在需要时进行更正，直到结果令人满意。

冗余 同一条规则或规则集是否在同一应用程序流程中出现两次？当针对两个共享上游功能的不同输出分别挖掘规则时，可能会发生这种情况。或者，它可能是简单疏忽的结果，例如多个团队成员无意中从相同的代码库中挖掘规则。规则属性用于标记重复。

另一种形式的冗余发生在语义上相同的规则从不同的流程（例如订单详细信息和提案）中分别挖掘出来，并使用不同的名称时。这将在下一步解决，您将在下一步将候选规则转换为业务规则格式。

完整性 除了预定义的例外情况外，所有应用程序功能是否都已涵盖？匹配挖掘的规则来源与总体来源的规则覆盖率报告可以提供答案。

相关性 每个挖掘出来的规则都可以被视为候选业务规则吗？虽然这还没有进入 SME 审查阶段，但可能存在某些结构，经检查后，显然无关紧要，不应包含在要审查的规则范围内。安全验证规则、维护例程和超出范围的操作都可能属于此类。在规则属性之一上指示相关性。

11. 候选规则转换为业务规则格式

在前面的步骤中，候选规则已经过挖掘和审查，反映了遗留应用程序的行为。这些规则严格遵循应用程序的流程流程和操作。

现在需要一个转换步骤，将候选规则转换为可供审查的实际业务规则。此步骤由应用程序专家、规则架构师或主题专家执行。在审查和转换后，捕获的业务规则反映了当前的现状，作为目标环境的基线或比较。

重新格式化为业务规则表示法

如果候选规则是手动构建的，它们可能已经采用所选的业务规则格式。在其他情况下，它们可能以技术格式捕获（例如从源代码中剪切和粘贴），并将需要一些修改和重新分组。

如果使用了自动规则检测工具，则生成的候选规则可能会有点类似于业务规则，通过使用词汇表定义将业务名称放在规则名称、数据元素和控制条件中。但是，即使在规则验证步骤之后，大多数批准的候选规则也需要进行调整以符合所选的业务规则表示法。

图 7：业务规则转换

事实建模和规则规范化 由于其程序性，遗留应用程序往往将业务逻辑锁定在特定于流程的孤岛中。但是，真正的业务规则独立于流程，应该如此维护。

在我们的示例中，订单详细信息条目和建议条目事件的规则已分别挖掘并放置在规则集中。它们都是独一无二的吗？经过进一步检查，它们中的大多数逻辑在设计上是相同的。从业务的角度分析结果，任何客户文档（无论是订单还是建议）的各个部分之间都存在共性。

从工具的角度来看，此时可能更有意义地切换到业务规则管理系统，将从规则挖掘工具中挖掘出来的规则导入，如下面的集成部分所述。

使用 BRMS 或可视化建模工具，构建一个事实模型，反映在现有应用程序中发现的重要业务实体及其相互关系。这些将链接到挖掘出来的业务规则，并作为目标规则模型的基线。

在我们的示例中，事实模型的一部分将是

完成此操作后，将业务规则规范化为表示所需的业务级别语义

…从而使客户文档处理规则适用于订单和建议。

分组和排序

此时，将考虑生成的规则分组和排序。一个关注点是规则与其他规则和规则集之间的触发关系。由于候选规则通常是从第三代语言应用程序（如 Cobol 或 PL/I）派生的，因此它们以程序方式自动排序。转换为声明性模式将消除本质上非业务的程序元素。

如下图 8 所示，反映真实业务需求的声明性关系将被建模为规则与其他规则或规则集之间的触发器。在大多数 BRMS 环境中，单个规则可能会触发多个规则和规则集，其中每个触发规则或规则集的排序仅在运行时预编译或解析。

图 8：现状业务规则模型（事件驱动）

主题专家审查和批准

一旦挖掘出来的规则被转换为业务规则，它们就会被交给主题专家 (SME) 和/或业务分析师进行审查和批准。

通常，SME 此时不会对规则进行重大更改。规则挖掘工具可能包括规则归属功能，以帮助 SME 并使他们能够将业务规则标记为

• 已批准或拒绝；
• 重新分类到其他类别；
• 使用文本描述属性添加其他信息。

规则挖掘工具通常还提供以预定义的 SME 活动为中心的 Web 门户。这可以大大加快审查和批准流程。

12. 报告制作

业务规则报告以硬拷贝或数字格式创建。规则挖掘工具会生成报告和图表，以在您选择的上下文中描述详细或摘要规则信息：层次结构级别、分组、搜索结果。这些报告既作为审查步骤中的参考，也作为记录的文档。

13. 与目标环境集成

根据所采用的现代化策略，与其他环境的集成需求将有所不同。

业务规则开发

采用业务规则方法的重新开发通常会利用 BRMS 创作环境。这些工具通常包括 XML 导入功能，用于定义“现状”业务规则空间，允许规则开发人员有选择地重新使用被认为与目标环境相关的候选规则。这将提供从新部署的规则到其遗留来源的宝贵（有时是至关重要的）可追溯性。

传统开发

这种方法通常涉及使用全面的开发工具包构建 Java 和 .NET 应用程序。通常，UML 模型将用于在实际代码生成之前定义逻辑应用程序视图。

在这些环境中，挖掘出来的业务规则可以作为 UML 类中的行为附加，以利用它们。例如，包含 Order_Discount 作为属性的 Order_Invoice 类，还可以包含 Calculate_Order_Discount 作为类行为。此行为可以从执行相同功能的挖掘出来的业务规则中派生（并可能导入）。

BPM

流程管理 业务流程管理 (BPM) 工具促进流程模型创建以及与底层规则和可执行服务的链接。它们还包括定义工作流规则（使用 BPEL）的能力，以管理活动节点之间的手动和自动转换。

在这种情况下，每个活动节点都可以由业务规则实现。规则集和支持的活动之间可能存在多对多关系。使用相关的挖掘出来的“现状”业务规则填充 BPM 流程可以“闭环”业务分析师，并显着推动 IT/业务对齐目标。

需求管理

供应商产品还包括需求工具，这些工具可以定义高级用例、详细流程图和活动，以实现有效的应用程序开发和管理。在这些环境中，可以导入挖掘出来的业务规则，并将其附加为核心需求或活动节点的文本注释。

SOA 使能

现有应用程序的服务使能涉及代码重构和作为服务封装部署。规则挖掘步骤在源代码中查找细粒度服务并提供所需的服务组件方面非常宝贵。例如，计算订单折扣的自动规则检测结果将包括所有导致最终计算的代码段。通过仅使用该代码（及其依赖项）创建组件切片，可以将订单折扣计算重新部署为服务。

14. 主动规则管理

我们预计大多数应用程序将在未来几年内继续维护和维护。从它们中挖掘出规则后，至关重要的是要继续更新它们，并使其与未来的应用程序更改保持同步。规则挖掘工具提供维护和管理功能，包括

• 即使规则已因整体源代码更改而移动，也要自动将规则与原始代码段对齐；
• 手动规则更改的审计跟踪；
• 允许在规则挖掘后进行单个或批量更改的“更改器”例程。

结论

对业务规则挖掘的定义明确的方法将使业务上下文化能够尽早地在流程中进行。上下文化步骤不仅有助于正确地构建挖掘出来的规则，而且还将减少规则挖掘投资，使其只专注于感兴趣的关键和动态业务流程。无论采用哪种应用程序现代化策略，本文介绍的最佳实践和工具辅助方法将帮助您以更低的成本、更少的重复和更高的质量结果实现您的目标。

注释和参考文献

1. NEUER，Mannes。 语境为王：规则挖掘的实用方法