内容


策略和规则 —— 提高业务敏捷性

第 1 部分:业务敏捷性支持

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 策略和规则 —— 提高业务敏捷性

敬请期待该系列的后续内容。

此内容是该系列的一部分:策略和规则 —— 提高业务敏捷性

敬请期待该系列的后续内容。

目标

任何架构的最终目标都是指导企业实现预定的业务目标、战略目标和战术目标。确认了企业对敏捷性的需求之后,可以使用最佳实践并调整特定产品来满足业务需求,架构师可以成功地构建完全自动的智能化解决方案。策略和规则的应用和管理的多样性应该被视作一个机会,有可能大大提高业务服务的敏捷性,但是这也要求企业为业务规则和业务策略的管理建立自己的治理原则,把它们当作第一等业务资产。

第 1 部分的主要目标是讨论策略和规则的定义,为评估策略和规则之间的关系以及业务分析师、架构师和 IT 人员之间的关系提供上下文。首先简要解释业务策略和业务规则之间的关系,这有助于为评估如何单独使用或结合使用策略和规则实现/实施业务战略、战术和行业规范建立上下文。我们希望说明架构师如何帮助业务和 IT 部门实现预定的业务战略目标和战术目标。为了实现这个目标,我们将解释词汇的定义,给出关于词汇的使用方法及其相互关系的一些论断。本文的第 1 部分比较抽象,因为这里的重点在于关系和业务敏捷性战略目标的表述,它们在本质上是动态的。

概述

在第 1 部分中,首先为其余部分中使用的词汇提供统一的定义。为策略和规则提供统一的定义之后(无论您是否完全同意我们的定义),我们就可以讨论策略类型和规则类型的关系以及每个类型适用的场合。

“动机” 一节为我们的词汇定义提供一个行业标准上下文(参考 OMG 的成果)。这一节提供我们通过参考得出的一些论断并根据本文的目标进行解释。这个行业上下文的适用范围很广,本文主要关注其中一部分。

“策略和规则的抽象层次” 一节把应用这些论断的战略表述为一组技术问题。业务逻辑的架构并不是新的,而且许多新的敏捷性需求可以在以前未实现的战术目标中看到。但是,软件开发方法是新颖的。

“自顶向下 —— 业务层” 一节帮助读者认识到敏捷性的关键方面是元素之间的关系。实现敏捷性就意味着希望一个东西影响另一个东西的行为。如果不加指导,敏捷性会导致不可靠。为了实现业务敏捷性以支持更好的绩效,业务、架构和操作必须与一套共同的战略目标保持一致。业务分析师定义这些业务指示和业务战略目标。

建立战略目标和实现战略目标是不同的任务。在 “架构层” 一节中,讨论业务分析师和架构师之间的关键关系,研究解释业务战略目标和实现敏捷的架构的困难之处。

第 1 部分最后研究另一个重要的关系,操作层。任何成功的业务都依赖于工作的划分。业务指示由架构师解释,由操作人员维护。为了实现业务敏捷性,一定要研究业务上下文中的各个部分 —— 操作事件可能会影响业务。

词汇的定义

在本文中,我们使用以下词汇定义:

  • “策略” 的一般性定义是对意图或指示的陈述。在计算机系统中,我们认为 “策略是根据给定的条件从候选过程中选择行动过程”。
    • “业务策略” 是一种业务指示,表述在一组业务条件下企业希望发生的行动过程。
  • “规则” 是权力和控制的执行。
    • 业务规则在企业的治理模型下直接执行业务控制。

策略和规则之间的关系是,可以通过派生出一个或多个业务规则实现业务策略。业务指示由业务策略和业务规则的组合实现。对于由特定的业务策略治理的业务过程这样的解决方案,通过调用适当的业务规则按照策略指导过程。

图 1. 策略和规则作为业务指示
策略和规则作为业务指示
策略和规则作为业务指示

动机

在任何企业中,都有业务战略、业务战术、业务战略目标和业务战术目标,可以在业务应用程序中实现这些。这些业务应用程序有关键的业务指标,可以在任何时候度量这些指标。企业常常与相似的企业合并、联合组建新公司或者搬迁到其他国家,这可能会带来一个难题。每个组织可能有自己的业务指标,企业必须适应行业规范的变化,在进入新市场时企业必须适应新的规范。因此,新的业务难题是不仅要满足当前的业务战略目标,而且要设计出有适应能力的战略,既可以满足短期需要,也可以适应长期的业务变化。

这意味着许多业务软件开发人员需要设计出以提供灵活性为目标的业务应用程序。如果这些业务服务必须在环境变化时保持连续性,还需要确保健壮性。还要优化业务绩效。任何项目的第一步都是捕捉并建立一套统一的业务需求。这些需求中的一部分应该表述为业务策略指示。还要确定哪些需求可能长期不变,哪些(在设计阶段早期识别出的)需求可能需要经常变动。尽早发现可能出现变动的地方可以改进项目的设计和实现,从而减少以后的修改和产生的费用。

大多数治理组织按一套策略执行日常操作。以民主政体为例,人民通过投票建立一套法律,他们相信可以在这些法律(即规则)的约束下实施任何公民策略。公民策略可能会发生变化,因为执政的政党或个人在任期内有权选择应用策略的方式,但是约束实施的法律在很大程度上是不变的,尽管需要司法系统的监督。业务敏捷性需要相似的关注点隔离和一套控制方法,从而检查系统的操作是否符合预定的业务策略。

首先,给出一些论断:

  1. 企业建立一套业务方针,按业务治理生命周期管理它的资源。在这种业务环境中,建立良好的治理需要定义实现敏捷性所需的策略集和规则集。
  2. 如果业务条件可能发生变化,而且可以通过定义一组方针来反映业务条件范围,那么把一些业务需求表述为策略可以提高敏捷性。如果随着业务条件的变化可以识别并治理这些业务策略,就可以让业务规则的执行更加敏捷,可以在策略范围内适应变化。
  3. 业务规则可能有自己的变化生命周期,企业可以监视它的功能和业务条件的小变化,据此改进或修改现有业务过程中的行为范围。根据组织使用技术的成熟度不同,可以在一些地方通过规则评估和自动地执行业务操作过程(即 “IT”)来提供强大的业务控制。
  4. 通过在整个组织中(也就是在业务应用程序和 “IT 过程” 中)应用补充性技术,可以在操作过程中实施业务策略,这可以在实施必需的或法律要求的行为方面为业务和 IT 部门提供有效的平衡。
  5. 业务规则和业务策略的全面战略管理应该允许灵活地定义业务资产(由策略和规则支持),可以随着业务条件的变化修改它们(在适当的控制下)。敏捷的控制可能要求在架构良好的基础设施中为业务策略和业务提供单独但是相互协调的治理生命周期,这会为业务提供许多好处,比如改进业务调整、减少产生价值所需的时间、减少修改量和成本以及为业务用户提供更多控制能力。
  6. 在把业务规则和业务策略具体化时,企业需要对操作策略(比如访问控制策略)和操作规则(比如服务水平协议)进行标准化,以便像管理业务资产那样高效地管理和协调规则和策略的操作资产。

另外,策略和规则的业务和操作资产应该采用一致的管理方式,这让企业可以修改业务资产,还可以报告修改的操作实施。为了支持指定的业务约束和战略目标,在 IT 方面和业务方面可能涉及不同的技术,因为 IT 和业务部门关注的细节层次不同,但是最终目标都是协调地管理操作资产,支持指定项目的业务需求或业务战略和战术。

策略和规则的抽象层次

许多客户希望自动执行业务操作,与他们合作多年之后,我们发现了一些模式,这些模式反映如何分解业务运营所需的元素。任何企业都有希望实现的东西(它的战略目标和战术目标),任何企业都需要表述应该按什么策略管理业务资产以实现这些战略目标和战术目标。可以以不同的方式度量企业实现其战略目标和战术目标的程度,包括捕捉审计策略数据、业务指标或 Key Performance Indicator (KPI)。因为业务人员希望而且需要只关注业务,而不是关注计算机技术细节,所以我们需要以另一种方式划分控制层次。我们认为可以在三个层次上捕捉并治理控制 —— 业务层、架构层和操作层。

架构师负责确保整个业务架构的完整性,他们的职责常常包括把业务战略目标映射到(或者说转换为)当前实现业务过程和业务服务的硬件和软件资产[架构层]。架构师还与 IT 主题问题专家密切协作,确定如何在受控的环境中高效且有效地运行硬件和软件[操作层]。架构师需要涉及许多问题,从安全性、访问控制和服务水平协议,直到业务工作流、事件处理、信息管理和业务规则。

图 2. 业务指示的不同类型,指定战略目标和战术目标的策略
业务指示的不同类型,指定战略目标和战术目标的策略
业务指示的不同类型,指定战略目标和战术目标的策略

我们通过与客户交流发现,使用这三个抽象层次有助于所有参与方更具体地讨论解决方案,而不是泛泛地讨论敏捷性问题,因为这种方式承认任何解决方案都可能包含来自多个视角的不同需求。确认某个东西属于业务层问题(例如,高层需求 “保护业务资产” 的表述)可以帮助您专注于指定需求和确定适当解决方案的资产(例如,开发业务指示板而不是为机房中的所有资产创建二进制表示),因为不同的解决方案可能使用不同的工具和报告机制。因此,一定要一直想着敏捷性问题的业务战略目标和战术目标。

自顶向下 —— 业务层

业务指示和战略目标

当组织决定对业务过程进行自动化之后,第一步是捕捉业务需求,从而形成一套业务指示。业务指示包括一套要实现的战略目标和一套根据战略目标度量结果的业务指标。可以使用不同的方法表述业务指示,但是 OMG 已经定义了一些模型和技术,在讨论业务策略和业务规则的解决方案时,我们应用它们来分解企业通常需要的元素。完整的信息参见 OMG Business Motivation Model 文档 [请参考 http://www.omg.org/spec/BMM/1.0/,因为我们参考它们讲解捕捉和表述业务战略目标和战术目标的常用过程]。

业务指示、业务策略和业务规则

在概念方面,OMG "Business Motivation Model" (BMM) 在更大的业务组织和决策概念性框架的上下文中,提供了一种研究规则和策略之间的关系的方法。它以这种方式反映一些治理原则。

  • 在 BMM 模型中,需要理解企业的愿望;“把企业的愿望(它的愿景)、它的行动计划(它的使命)和愿景的细化转换为战略目标和战术目标,通过确定战略实现战略目标,通过确定战术实现战术目标”。

指示可能由一些业务策略和业务规则组合组成,OMG 文档对比了策略和规则,大意如下:

  • 业务策略
    • 在企业的控制下管理业务策略。
    • 业务策略治理 业务过程。
    • 可以用自然语言表述业务策略,自然语言的含义可能不明确。
    • 由于自然语言具有模糊性,业务策略常常无法直接执行,需要加以解释。
  • 业务规则
    • 在企业的控制下管理业务规则。
    • 业务规则执行 业务过程的行动。
    • 用标准的业务词汇表 (SBVR) 表述业务规则,没有模糊性。
    • 因为业务规则是用特定的 SBVR 定义的,反映特定的业务行动和资产,这些行动和资产的定义是公认的,所以业务规则可以直接执行。

一下子确定所有业务元素(策略和规则)很困难。因为大多数策略和规则会随时间变化,所以在项目中实现策略和规则很可能需要多次迭代,良好的设计方法应该适应这个现象。下图是这种方法的典型形式,它说明可以通过回答一些问题对以前指定的元素进行细化,而且一定要确保策略和规则有相关联的度量指标,可以根据这些指标衡量策略和规则是否成功。

图 3. 业务指示的生命周期
业务指示的生命周期
业务指示的生命周期

在开始这个任务时,任何组织都会尝试把一些行为表述为业务规则或业务策略。随着发现更多细节,应该重新检查或调整概念。在确定业务指示的过程中,一定要确定供业务分析师和业务架构师使用的资产。应该问一些问题:业务架构师期望如何监视策略?业务架构师打算如何提供这种监视功能?业务分析师期望如何编写业务规则?通过了解这些期望,架构师可以评估和选择支持业务的最佳方法(业务策略、业务规则或它们的组合)。

应用这种技术的简单示例是反洗钱 (AML) 法这样的一般性业务方针。当这部法律生效时,金融行业的企业已经在正常运营了。它们别无选择,只能根据这部新法律更新自己的总体战略。在许多情况下,这意味着增加新的业务过程、业务策略和业务规则以满足 AML 法的要求。常常还需要增加新的业务战略目标和审计指标,或者调整当前应用业务的审计实践。围绕反洗钱 (AML) 的一般性业务指示可以声明某些一般性方针,比如:金融机构不应该接受可能会让它和它的服务提供者面临罚款和其他处罚的支付。

如果尝试根据这个 AML 指示示例构造一套具体的业务策略和业务规则,我们会发现最初可以把这个业务指示表述为一个业务策略或一个业务规则,但是表述为一套业务策略是最自然的。

支持这个业务指示的业务策略可能像这样:“代理人和职员总是应该知道用于支付费用的客户资金的来源。” 或 “对于常规支付,银行不接受金额达到或超过 $10,000 的现金支票、邮政汇票、银行汇票和旅行支票。”

再举一个例子。业务分析师可能在典型的信用交易中发现一个一般性业务指示,其中包含 “我们公司不向信用差的客户销售任何东西” 这样的一般性陈述(业务指示)。

每个 LOB 可以把这个指示解释为更具体的东西。如果有提供信用评分的通用服务,就可以细化策略:

清单 1. 表述为业务策略的信用指示
Business Policy: XYZ will not sell anything to a customer whose account has been 
determined to have a bad credit rating

在这些活动中,一定要认识到一点:业务策略的有效性取决于它的精确性,业务策略应该尽可能用业务词汇表表述需求。例如,分析师知道这个业务控制的资产子集,但是不一定会逐一列出它们。业务控制的粒度反映在它的业务词汇表中,因此只有在指示与具体的业务资产相关联时,才能收集指标和实施业务策略。业务策略可以声明 “不向信用差的客户销售”,但是如果无法区分信用评分良好和信用评分差的客户的请求,策略就只能停留在纸面上,无法有效地应用。

如果有良好的业务词汇表,业务分析师和架构师就可以使用更具体的词汇和规则表达式捕捉指示,而不必用自然语言表述业务策略的语义(比如 “不向信用差的客户销售”),这样的表述需要由业务过程加以解释。在下图中可以看到,规则可以表述策略的语义。例如,如果业务词汇表把 “信用评分差” 定义为在信用报告中评分低于 500,那么从以上业务策略派生出的业务规则可以这样表述:

清单 2. 按业务词汇表表述为规则的信用指示
When one of the credit reports has a rating below 500, mark the borrower as blacklisted.

If a customer is black listed then refuse the business and warn  the customer with an
explanation message.

另一方面,能够解释业务策略的业务应用程序效果更好。使用业务策略还是业务规则?这是一个业务决策,应该根据业务价值以及敏捷性和业务功能的目标决定。

基于同一个指示的规则和策略的区别是是否 “可执行”(源自 OMG 的定义),这说明了目前在业务层上策略和规则概念之间为什么界限不清,还说明了为什么收集业务指示是一项重要的活动。我们认为这两个概念(策略和规则)在业务层上是对等的,在许多业务解决方案中同时需要策略和规则。如果您接受这个论断,我们就可以开始使用标准业务词汇表帮助我们选择正确的方法。假设我们已经通过业务分析收集了一套业务指示,下一步是考虑如何设计一个解决方案来反映这些指示并实现业务战略目标。

业务战略目标、战术目标和结果

在概念方面,OMG "Business Motivation Model" (BMM) 还提供一个用来捕捉和跟踪与业务指示对应的业务结果的结构。BMM 承认在实现业务指示的地方可以按不同的战略跟踪业务结果。

如果说业务策略是实施业务指示的手段,那么证实实施结果就是确保指示有效且符合业务战略目标和战术目标的关键。策略实施引擎可以记录审计信息或实现事件机制,让企业可以了解实施的结果。如果通过 BRMS 实现业务规则,企业可以通过审计信息或事件机制了解执行规则的结果。

业务结果或指标可以定义为定性的或定量的。

  • 业务战略目标(Business Goal)陈述在业务指示发挥预期作用的情况下应该实现的业务状态。这些业务战略目标通常定义为定性的,还有实现目标的预期时间。
    • 业务战略目标 —— 明年把所有系统转换为使用新的 AML 过程。
    • 业务战略目标 —— 确保可识别出个人的信息得到保护。
  • 业务战术目标(Business Objective)是为了实现业务指示在特定的检查点应该达到的绩效指标。这些目标通常是定量的,与应该实现它们的时间点相关联。它们常常可以定义为 Key Performance Indicator (KPI) 或 Critical Success Factor (CSF)。
    • 业务战术目标 —— 在使用新的 AML 过程的第一个月,预计会完成 10,000 次 AML 检查。可以定义 KPI 来度量每个月完成的 AML 检查数量以及其中发现了问题的百分比。
    • 业务战术目标 —— 在实施 PCI 遵从性方面,通过跟踪失败的登录尝试,识别正常数量和系统受到攻击时的非正常数量,确保企业尽到勤勉义务。

架构层

在架构层上,架构师主要关注 “如何实现”。一定要了解现有架构的控制功能,这对于判断是否可以作为规则(作为可执行元素)实现收集的指示以及哪些指示可以表述为架构策略很重要。

对于上面的示例,架构师可能断定一个业务指示(例如 AML)应该应用于 “出纳员”。这个指示暗示银行中有称为 “出纳员” 的业务角色并有担任这个角色的人。为业务过程提供敏捷性意味着,在架构中应该识别哪些是人工任务,哪些是自动的任务。在架构中可能有 “出纳员” 任务的定义,但是随着新指示的出现,这个角色可能需要改变。例如,这个任务可能由人工任务变成自动的工作流。在架构层,一定要检查每个指示,根据许多条件决定是否把它表述为策略,以及如何表述为可实施的策略。架构师可能会发现,为了从业务角度识别出谁是 “出纳员”,不仅需要一个新的相关业务策略(说明如何确认谁是出纳员),还可能需要在用户供应的操作元素中包含这个业务角色定义,让用户管理组件可以建立相应的操作访问控制策略(例如,出纳员有权访问银行事务)。设置出纳员策略这样的操作安全策略并不少见。为了访问任何业务资产上的任何类型的数据,还可能需要用不同的治理模型确保以不同的方式识别人员(业务策略)。

一定要收集全面的业务指示。架构师需要帮助企业细化指示,确保现有的架构能够跨业务过程的子领域以及在操作过程的子领域(例如访问控制、用户识别、密码管理)内支持规则和策略的组合,从而完整地实现解决方案。

通过定义一个能够提供信用评分的通用架构服务,可以在架构级支持另一个贷款风险控制指示。可以使用 Business Rule Management System 技术支持通用可执行元素的收集和重用。根据业务词汇表的粒度,这个规则可能是一个算式或条件的表述,它决定接受还是拒绝贷款申请,或者定义贷款的条款和条件。决定规则的形式也是架构师的任务,因为他们负责把业务战略目标和战术目标具体化。一定要记住,在做出这些架构选择之后,仍然需要跟踪业务指示和业务策略。架构师定义要收集哪些指标以及它们与什么地方有关,从而确保操作元素在运行时产生业务消费者需要的业务数据。

组织的成熟度(相对于数字资产/资源在组织中的用途以及业务过程的自动化和优化)总是会影响交流或实施业务策略的水平。即使服务是完全自动的,也一定要捕捉与业务策略的实施相关的业务目标或参与方。在某些情况下,“业务策略” 可能是要求用户阅读的东西(例如网站上的隐私免责声明)。在实现需要用户认可的业务策略实施和业务指示时,有多种技术选择,可能需要编写动作(例如,在用户申请业务旅行时应该问他们是否会遵守业务旅行策略)。另一方面,为了优化和在整个组织中保持一致性,实施可能必须是中间件的自动化部分。在这种情况下,最终用户可能看不到实施方法,也不需要让用户看到(例如,规则可能实现一个安全策略,对所有离站消息进行消息加密,最终用户不需要启动加密)。

有很多种技术选项,所以一定要把策略和规则看作实现敏捷性的重要方面,要把收集指示和提供业务策略实现的可跟踪性当作根本性的业务需求。无论是编排工作流中的人工任务(例如用于人员的 BPEL),还是在 BPM 套件中自动执行业务过程,都可以使用规则引擎和策略管理增强业务策略实施战略。收集业务指示并捕捉敏捷性业务需求之后,架构师负责收集可供选择的实现方法。在这个方面没有通用的解决方案,业务分析师、架构师和 IT 人员必须根据价值和成本做出集体决策。

为了说明这些原则,我们继续考虑前面的业务指示,但是现在从架构层的角度来研究。

围绕反洗钱(AML)的业务指示声明:金融机构不应该接受可能会让它和它的服务提供者面临罚款和其他处罚的支付。

这个业务指示的目的是保护企业本身,让企业不会由于执行它的业务应用程序而成为被告。对于 “金融机构不应该接受可能会让它面临罚款的支付” 这样的业务指示,可以以几种方法确定实现它所需的高层业务需求。

在过去,“金融机构” 常常被具体化为 “人员” —— 例如,金融机构的人员培训包括向每个业务线传达一套警告,它们规定在接受支付或向第三方支付方面哪些业务行为是适当的。在当今的企业中,人员培训仍然是重要的预防措施。但是,如果银行的职员分布在多个大洲,指望以人工方式实施这样的策略可能不现实。尽管可以通过划分角色让任何职员都不支持所有交易,还可以让其他银行职员(审查账户交易的检查员)能够看到账户,但是为了实现这个指示,可能需要用自动的系统评估交易(例如电汇和其他同业交易)。

在 “有技术头脑” 的金融机构中,实现这个目标更高效的方法是,让架构师捕捉这些业务需求,设计自动的业务和技术服务,从而指导和控制人员的行为。架构会确定要评估的规则,通过自动地分析记录和交易发现任何可能违法的支付。新的架构在业务经理工作流中包含一个新的管理批准动作,动态地标记为 “危险” 的交易会触发这个动作。

架构师面对一个艰难的任务。什么架构结构可以帮助解决方案架构师?

在细化业务指示的过程中,架构师可以先使用业务规则中定义的分类和次级分类。常用的两个子类型是结构化类型和行为或操作类型。

图 4. 业务指示 —— 业务规则子类型
业务指示 —— 业务规则子类型

我们先处理结构化规则类型,因为这些规则反映业务数据领域中具体的项目,或者粗略地反映业务范围。结构化规则的示例是 “客户必须是国内的常驻居民才能开设新账户”、“每次租赁必须有且只有一个租车类别” 或者 “一个银行账户只与一个客户相关联”。这些结构化规则影响业务资产或业务工件的创建,反映在业务过程或业务模型中。

建立这些结构化资产之后,通常会通过一个行为业务规则反映一些可实施的动作,它常常与业务过程或业务模型的具体实现的特征相关。当然,这里也要做出选择。行为规则(有时候也称为操作规则)可以进一步分解,从而根据过程实现的粒度支持不同的实现模式。在下图中,我们根据自己的经验和各种客户实现给出一些行为规则示例。

图 5. 行为规则的进一步分解
行为规则的进一步分解
行为规则的进一步分解

在任何规则分解中,一定要寻找模式。行为业务规则有两个常见的特征 —— 表述约束或者表述指导方针。

约束是必要条件,即必须完成的事情。约束可以使用 “必须具有” 这样明确的表述,也可以是比较隐含的,比如 “它需要”(“需要” 常常意味着 “必须”)。

指导方针指出某种情况是不适当的(常常有相应的警告消息)。

过程流子类型一般用来表述工作流的参数或元数据。例如,业务过程如何控制步骤的执行和活动的次序。在某些环境中,区分过程流规则和业务逻辑规则(它们决定用来控制过程流走向的参数值)可能有帮助。

决策子类型根据数学等式从现有数据创建新信息。

ECA(事件条件动作)是一种特殊的规则模式,它们在发生某个事件时检查条件。大多数 ECA 规则使用时间操作符搜索与创建或出现的时间相关的事件。例如,“筛选前 x 秒内具有指定的符号名的事件,并求出计算值 = 价格 * 数量 的总和” 这样的规则陈述需要一个规则表达式,为了支持执行这个表达式,规则引擎在运行时需要一种移动时间窗有状态机制。捕捉时间条件的语义是规则分析师在分析阶段的一项非常重要的任务。

动作使能器子类型在系统中启动另一个动作。例如,规则的执行触发一个业务过程,这个过程异步地调用一个服务。这个类型代表业务用户的视角,主要用于通过规则触发业务过程,比如调升、审计或评估过程。

推导子类型常常体现非常敏捷的方法。它的前提条件是行为规则的内容可能会影响对规则的处理。它生成或更新数据元素,这些新条件可能导致重新处理规则。

一定要注意一点:ECA 规则中介绍的时间操作符是一个通用的概念,可以应用于其他规则子类型中的条件。没有专门用来支持时间约束的规则类型。例如,在过程流中可以定义计时器条件,当计时器触发时在过程中执行指定的任务。例如,条件陈述 “如果在两小时内在同一加油站用同一张信用卡进行交易,那么第二次交易可能是欺诈”。这个条件可以应用于推导规则(创建欺诈),如果交易事件是流的组成部分,还可以应用在流处理陈述中。

这主要属于架构设计的范围。涉及策略和规则的部分是决定控制是静态的,还是某些特征会随时间或其他业务变量而变动。例如,对于银行业务,一个重要的变量是地理位置。除了国际规则之外,在不同的国家要应用不同的规则和策略。

操作层

图 3 说明,除了业务层和架构层之间的生命周期之外,在架构层和操作层之间也有生命周期。所有参与方必须认识到常常需要通过另一次迭代把业务指示细化到操作层。我们还认为信息技术 (IT) 是一种业务功能,操作环境常常有自己的策略约束,架构必须适应这些约束。上面示例中收集的业务指示可以被看作反映一个或多个 LOB 的要求。另外,首席安全官或首席信息官可能需要表述和控制其他业务指示。

例如,架构师在定义解决方案时需要了解运行时或操作策略决策点 (PDP) 或策略实施点 (PEP) 及其粒度,这样才能设计出与操作策略管理提供的控制范围匹配的解决方案。如果当前的操作环境无法实施架构师(通过策略编写点)表述的策略,那么架构师需要与 IT 人员协作,让新的指示能够实施。为了保持一致性和优化,组织常常让 IT 部门负责选择在什么地方和如何实施跨 LOB 的策略。例如,消息安全策略常常需要在操作基础设施中的某一位置(比如 DMZ)一致地实施。实施策略的设施类型或总体网络保护指示常常会影响操作策略约束。

委托给 IT 的业务指示应该确保 DMZ 中的任何策略实施能够实现业务策略原来表述的业务指示,但是用来实现这个目标的技术可以以多种方式实现,包括使用规则。因此,图 3 所示的策略和规则细化过程包含反复调整操作度量,从而提供操作指标和业务指标的关联。IT 和 LOB 都可以使用规则技术,如果运用良好的架构和重用实践,架构师可以构建一个通用的结构来满足 IT 和 LOB 两方面的需求。

策略和规则实施的细化对于整个生命周期很重要。例如,在研究每个抽象层和业务指示时,会找到一些传统上属于 “操作安全性” 的东西,例如访问控制。从最高的概念层来看,每个企业都需要通过策略规定谁可以访问什么,但是没有 CEO 愿意让访问控制策略的粒度细到每个职员,规定每个人可以访问的记录(除非只有不到 10 个职员)。大多数 LOB 对于自己的资源有自己的访问 “策略”。为了优化对访问控制的管理,IT 组织可能需要一个或一组策略实施点。在构建跨 LOB 的操作策略实施机制时,负责信息技术基础设施的架构师可能会建议在策略实施战略中使用规则引擎,决定对 LOB 内或跨 LOB 的事务(比如服务的组合)应用哪个策略。常常使用规则引擎在操作运行时环境中实现和实施策略 “决策”。

下图说明用于管理安全策略的一种操作策略实施架构风格。

图 6. 操作策略实施
操作策略实施
操作策略实施

再举一个例子。架构师可能会发现企业需要共享的架构策略决策点,可以在这个点上跨多个过程或多个应用程序管理、共享和重用业务应用程序决策。在操作层,这个策略决策点可以包含多个业务规则,它们一起实现满足业务策略指示所需的决策。

为了深入解释 BMM 原则,业务指示的捕捉(根据以上 BMM)还包括捕捉威胁和机会以及捕捉战略和战术(通常是架构问题)。

在不同的架构战略定义中,可以按每种架构风格细化策略和规则,然后应用于这些领域(业务策略、威胁和机会、战略和战术)。这些变体说明必须在业务人员、架构师和操作人员之间进行有纪律的交流(有时候称为治理),从而按特定的方法指导任何行动过程的定义。需要通过良好的治理实践确定具体业务问题的责任,包括如何从业务概念模型转到更具体的架构和操作定义。

业务人员对 IT 架构的常见需求:
适应性 —— 轻松地改变业务逻辑的能力。其动机是时间期限约束很严格,或者每周、每个月或每季度都可能出现频繁的小变化或重要变化。
可跟踪性 —— 需要以各方都能够理解的方式清楚地实现业务逻辑,因为业务单位和 IT 团队需要就业务逻辑形成公识。这要求以自然语言或接近自然的语言表述逻辑。
可审计性 —— 能够从业务动机跟踪到相应的策略执行,从而更好地理解决策背后的逻辑。
可重用性 —— 需要跨过程或应用程序共享业务逻辑,需要在应用程序/事务之间保持一致。
可管理性 —— 这个需求解决业务逻辑的生命周期管理。谁在什么时候编写什么,以及与基于规则的服务的维护和演进相关的所有问题。

由架构师承担这个责任的原因是,需要根据不同的架构风格(例如 SOA)进行改进,还必须考虑应用规则实现(例如在服务设计、服务选择和服务组合中)和策略实施机制的最佳实践。架构风格在某些方面还有自己的最佳实践,例如使用 Business Process Management 套件解决业务过程效率问题(通过提前确定 “与谁相关?”、“他们应该在什么时候参与?” 和 “他们需要做什么?”)。BPM 套件还可以支持人工和自动的参与者。在 BPM 中实现的业务逻辑链接到人员、任务和任务中要处理的数据。在决定什么人能够执行哪个任务时,大多数组织把人员分组为功能性的 “角色”,所以架构师必须与角色定义的业务所有者和用户供应任务的操作所有者合作解决这个问题。决定由哪个人执行某一任务的条件常常与分配给人员的角色相关,大多数组织把这些表述为业务策略,包括把角色临时分配给个人(例如由于休假)或者允许一个人把任务交给另一个人执行(委托)。Business Rules Management System 可以通过在 BPM 任务中添加 “为什么” 来补充 BPM,比如为什么采用某种方式、为什么做出这个决策。架构师可以鼓励业务分析师使用 BRMS 支持规则的可变性,使用预先定义的结构以结构化的形式(例如 If then else 语句或决策表、规则流、决策树、函数、规则模板)定义业务敏捷性因素,从而在业务过程中使用简单的部署模式、推论或模式匹配。

结束语

使用策略和规则实施业务战略和战术,进而实现和监视业务战略目标,这对企业有许多好处,包括降低成本、提供应对短期变化和长期变化的能力。用相同的预算完成更多工作,让业务用户具有更强的能力,这对于协调 IT 和业务人员的工作非常有积极作用。

要点是:

  • 业务、架构和操作策略都很重要,它们必须协调一致,在大型解决方案中尤其如此。
  • 业务策略和规则是对等的实体,可以派生和结合使用它们以实现业务策略指示。
  • 业务团队可以使用业务战略目标和详细的业务战术目标定义期望的业务结果,从而根据业务指示度量绩效。
  • 项目采用自顶向下方式,把业务指示逐步分解为详细的策略和规则。这样做的好处是可以提高可跟踪性,确保详细的策略和规则跨多个不同的操作系统协调一致,从而实现共同的高层业务指示和战略目标。

相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=592127
ArticleTitle=策略和规则 —— 提高业务敏捷性: 第 1 部分:业务敏捷性支持
publish-date=11292010