业务策略、业务规则、业务流程和业务主数据之间关系 - modernanalyst

数据质量对于组织系统的正确运行至关重要。在大多数国家/地区，有法律义务确保系统（尤其是金融系统）中数据的质量保持较高水平。

例如，澳大利亚审慎监管局的[APRA]审慎实践指南CPG235“管理数据风险”第51条规定：

数据验证是根据业务规则对数据进行评估，以确定其是否适合进一步处理。它是确保数据符合质量要求的一组关键控制措施。

在组织的生命中，有时会缺乏数据质量或缺乏数据质量的证据，而这种情况可能会上升到存在威胁的程度，例如：

• 数据质量不佳会对客户造成伤害，尤其是当它成为公众知识时。

• 监管机构发布可执行的措施。

• 从事并购活动。

• 迁移核心系统。

• 糟糕的数据质量阻碍了企业及时响应引人注目的市场力量的能力。

那么，什么是数据质量？

数据质量是衡量数据符合业务规则的程度：

• 如果数据是从外部来源获取的，则确定其有效性；要么，
• 如果数据是内部导出的，则确定其正确性。

因此，如果您没有可立即用作规则的标准，则无法衡量数据质量；如果您也没有“主规则”，则不能拥有“主数据”。

但是，我们所知的任何组织都没有在任何实际意义上实施“主规则”的概念。

 

业务规则高于数据和业务流程

十年前“需求与复杂性的野兽” 发表在《现代分析家》上，其相关性至今已被超过40,000次下载所证实。文章将需求规范作为传统系统开发生命周期中的重要薄弱环节。它介绍了一种新的需求收集和规范方法，该方法基于对业务策略的分析，以识别核心业务实体和管理其各自数据状态更改的规则。然后将这些规则捕获并描述为“决策模型”，以在前线系统中以可执行文件的形式实现。(banq注：DDD模型属于其中一种)

与当时（以及仍然）流行的以数据和流程为中心的需求方法相反，这种流行方法通常将规则定位为数据或流程的依存关系，而不是本身就是一阶最高要求。文章声称规则是相对数据和流程而言的更高要求，因为我们可以从规则中得出数据和流程的要求，但不能相反。

业务规则是业务策略的实现，业务策略还固有地定义了业务数据质量：如果数据进来，则要验证数据；或如果输出数据，则制造数据。无论哪种情况，规则都是数据质量的本质。为了清楚起见，要实施策略的规则必须是可执行的；而不可执行的规则是对规则的描述，而不是规则的实现；如果实现不能执行，说明就不能成为“真理之源”。

自该文发表以来的十年中，我们的业务已深入参与遗留系统的审计，修复和迁移，这些业务的范围涵盖养老金（数百万个会员帐户），保险（数百万个保单）和工资单（数十种一级公司和政府工资单）。

我们的审核，补救和迁移活动涵盖了过去50年来相关的大多数主要技术平台，包括许多早于关系数据库的技术平台。关于这些平台，我们重新计算和修正了可追溯到35年的个人帐户。

 

主数据管理

主数据是一个与计算本身一样古老的概念[2]。可以将它稍微概括地描述为计算机数据清单。Gartner当前的论文中提出了一个更正式的定义，如下所示：

“主数据管理（MDM）是一项基于技术的学科，业务和IT共同努力，以确保企业官方共享主数据资产的一致性，准确性，管理权，语义一致性和问责制。主数据是标识符和扩展属性的一致且统一的集合，描述了企业的核心实体，包括客户，潜在客户，公民，供应商，站点，层次结构和会计科目表。” 

实际上，如主数据管理所期望的那样，对数据的权威性分类和管理通常仅限于早期系统的Cobol抄写本，或者关系数据库和类似系统的数据定义语言[DDL]。无论哪种情况，我们都可以使用全自动方法在数小时内提取数据定义和数据本身。在我们的业务涉及的数十个系统的50年中，我们从未遇到这些原始的系统派生来源之外的可靠且准确的“主数据”描述。

无论有效性或以其他方式尝试“主数据管理”，房间里都摆着一头大象–甚至是一个完整而权威的“描述企业核心实体的一致且统一的标识符和扩展属性集”， Gartner提出的建议并没有告诉我们数据如何符合管理数据的业务策略。除了名称，数据类型和在分类系统中的相对位置之外，我们什么也没有。

例如，我们刚刚完成的一个项目从多个不同的源系统生成了一个本体-最终以“姓氏”和“姓氏”作为一个人的属性。如果不看基础代码，就无法在这两个属性之间进行区分，这两个属性有时对于同一个人在其中具有不同的值（提示，用法有所不同！）

 

主规则管理

如果没有同样强大的“主规则管理”，那么主数据管理是不可行的，并且主规则管理并不是我们在实践中发现的概念。

每当我们进行审计，修复和/或迁移时，我们需要找到的规则将使我们了解总体数据，尤其是其质量。我们认为，数据质量实际上是通过数据符合其规则的程度（即输入数据的验证规则和派生数据的计算规则）来衡量的。规则分析需要花费大量时间和精力。当我们只是孤立地查看数据时，通常会有一个起点，可以通过读取DDL或其他文件系统定义来自动得出一个起点，但对于规则却不是这样。一直是第一原则。所有数据可以告诉我们，某处必须有一些规则！

我们是否可以像处理数据一样自动提取规则？

答案是否定的，尽管我们确实有工具来协助这一过程。但更重要的是，完全自动提取规则无法解决问题，甚至无法解决问题！

有效的规则管理在系统刚开始时并未实行。结果，很长一段时间以来，整个规则有机地增长了，没有正式的结构-像杂草而不是花园，通常散布在多个系统和手动过程中。规则的多样性通常意味着，以不同甚至冲突的方式实现相同的规则意图。规则通常会以不明确的顺序应用于多个系统中。最终结果是，我们从源系统中提取的规则经常会被规范化，冲突，不完整，有时甚至是错误的。

此外，规则通常很少或没有依据。规则的背景，意图，理由和认可很少记录在案，甚至随着时间的流逝，口头讲故事也迷失了。正确性的定义变得难以捉摸。

规则从一开始就从未被视为一阶要求，因此也从未经历过定义的“规则开发生命周期”。简而言之，它们并不是以正式，有序的方式存在的，现在必须通过寻找它们对数据的影响来传递性地推测它们的实际存在。

因此，即使我们要自动提取规则，它们仍然需要经过严格的分析，规范化和重构过程，然后进行测试，最后进行正式（重新）批准。也就是说，我们需要回填“规则开发生命周期”以将规则提升到使用“主规则”所需的级别，而这不能通过自动提取来实现，因为所需的规则元数据根本就不存在。

在Sapiens 的一篇简短而引人注目的文章中，作者概述了许多公司的失败，这些失败最终归咎于“由于数据无知，分散的系统以及无法监督自己的流程而导致的问题”。摘自同一篇Sapiens文章：“穆迪最近审查了导致保险公司倒闭的原因，主要原因之一是一些保险公司不了解其定价模型。穆迪表示，为避免“以不适当的低价出售大量保单，保险公司将需要有适当的系统和控制措施，以快速识别和解决定价算法低估风险的情况”。

所有这些都可以通过实施“主规则管理”来缓解。

我们的结论：无论是由于监管压力，并购，降低迁移风险或需要改进规则治理以减轻巨大的商业风险，实施“总规则管理”迟早都将成为当务之急。到那个时候，它将不是可选的。

 

如何提取业务规则？

规则本身并不只是重要的人工制品；它们是您可以声称正确理解数据及其下游过程的唯一方法。正确理解数据是正确运行系统，从而履行法律和专业义务并避免上述概述的关键。

为了拖欠构建主规则，有必要能够将“主规则”作为已实现系统规则的镜像处理，以实现系统中每个实体（banq注：这是DDD实体对象应该是充血对象的原因，行为规则封装在对象的方法中），过去，现在，每个实体的每个值。和未来。无论是进行审核，补救还是迁移，都必须独立验证主规则。这些外部验证的“主规则”与系统自己的规则并行处理，以获取实时镜像数据，然后对数据进行流内增量测试。也就是说，我们为每个规则派生的属性创建两个值，然后计算它们之间的差（如果有）。

 

文章介绍了他们特有方法，点击标题见原文

 

#DDD领域驱动设计      #DDD实体模型      #业务流程BPM      #业务规则