内容


企业业务规则的 “胆固醇” 正在堵塞您的业务 “动脉” 吗?

了解业务规则管理系统 (BRMS) 如何为您提供帮助

Comments

简介

业务需要敏捷性和快速走向市场。当今日益复杂的 IT 系统及其相关业务策略组成了任何 IT 系统的核心。业务策略的更改由市场环境驱动。这些更改必须通过底层 IT 系统尽快吸收并呈现给最终用户。

传统的 IT 系统及其相关流程形成了针对业务的 “IT 黑匣子” 文化(如图 1 所示)。我们认为,利用这种文化来应对当今的挑战是不当且无效的,因此,也注定会失败。部分原因是过去的工具现在已经非常封闭和孤立。IT 部门借助了一些开发和部署工具(比如 Eclipse、JBuilder、NetBeans),但业务团队没有使用这些工具的理由。同样,业务团队使用的工具也不在 IT 部门的视野之内。

图 1. IT 黑匣子
IT 黑匣子
IT 黑匣子

在本文中,我们将查看一个 Business Rules Management System (BRMS), 这是一个协作管理平台,用于在企业业务规则生命周期过程中管理业务。BRMS 拥有一组工具和一个治理流程,可使用它们在业务和 IT 之间培养一种团队文化,打破 IT 黑匣子文化,从而提高业务和 IT 协调性。

针对业务及其环境的活力的要求越来越高。提前行动的优势是如此明显,以至于第一名拥有一切,第二名什么也得不到。公司和 IT 系统敏捷性不再是奢侈品,而是必需品。在很多情况下,公司迅速响应不断变化的市场活力的能力取决于 IT 能够以多快的速度对某个触发因素做出反应。

想象一下,假如有个人被诊断为胆固醇含量太高。他的医生建议他立即执行一个严格的节食健身计划,以避免患上与心脏相关的疾病。然后,这个人会考虑采用什么策略来根据推荐改进其生活方式。假如他严于律己,严格遵守推荐计划,那么几个月内他就会发现自己的健康状况发生了明显改善,可能患上心脏疾病的风险降低了。当他决定需要做什么之后,他执行策略的速度如何呢?现在假设他的策略形成和实际执行之间有几个月延迟,那么在此期间,他患上心脏疾病的风险将大幅增加。

将这个类比应用到当今的企业,我们可以看到,由于高风险的客户账户、不断膨胀的 IT 预算、很高的缺陷比率等因素,许多组织处于高风险情况下。在很多情况下,他们知道需要做什么,但由于组织的机器响应变化所需的时间,他们可能无法实现想要的结果。非常依赖 IT 的组织通常认为 IT 是组织发展的瓶颈之一。正是这个移动缓慢的零件导致组织在重返健康轨道的道路上行动迟缓。

组织通常没有深刻认识这个问题。IT 团队似乎工作得越来越努力,但它们对业务的响应能力却在一天天降低。当执行遭到延迟时,需要快速响应时间、获得竞争优势的业务计划也会受挫。

在本文中,我们将检查几个可能会延缓 IT 对业务的响应时间的关键因素。我们还将深入探索企业业务规则如何在解决 IT 瓶颈问题方面发挥作用。最后,还将展示如何战略性地使用 BRMS(例如 WebSphere ILOG JRules)来提高 IT 敏捷性,加快上市速度,满足当今的业务需求。

本文主要面向客户和 IT 之间的业务团队,包括业务分析师、IT 管理和高级管理、解决方案和技术架构师、推广人以及新技术早期采用者。

什么是企业业务规则?

企业业务规则描述企业适用的操作、定义和约束。它们可能包含 “如果-那么” 决策、约束、复杂流程以及策略,如图 2 所示。

图 2. 企业业务规则
企业业务规则
企业业务规则

如上所示,企业业务规则包含:

  1. 一组业务策略,它们是企业所依仗的运营逻辑。这些策略通常在 “如果-那么-否则” 策略声明中描述。
  2. 开展业务时必须遵守的约束或命令。
  3. 复杂的流程和流程流,规定工作的执行顺序,以实现想要的业务结果。

我们下面仔细查看一下这些业务规则组件。

“如果-那么” 决策

业务规则是一种高级声明,用于描述、约束或控制业务的某些方面。这些高级声明必须正式应用于一些 “如果-那么” 语句中,使它们变得精确和清晰。

规则捕获过程包括两个阶段:一是将表达策略所需的词汇表正式声明为一个概念模型;二是将业务策略逻辑表示为一些 “如果-那么” 语句。

例如,这些规则可能非常简单,比如计算 BMI (Body Mass Index) 和 FFM (Fat Free Mass);BMI 是一个简单的 “身高体重比” 指数,通常用于划分成人体重偏低、超重和肥胖。

词汇表创建好后,上述关于 BMI 和 FFM 的业务策略可以在 JRules 中通过以下业务规则实现,如图 3 所示。

图 3. 样例规则
样例规则

复杂处理

复杂流程实质上是一些难以概念化的规则。当今市场的形势要求公司在利用多个系统跨组织边界管理复杂流程方面做到更快、更高效。业务决策关注业务规则并对它们进行组织,将它们有效应用于具体业务问题中。理解正在制定的业务决策能够确保适当的业务情报得到收集和分析。

约束

约束是对提供解决方案中的自由度的限制。约束以类似于业务规则和技术需求的方式进行文档记录。许多业务规则实际上可以视作约束,事实上,可以将约束同时应用于技术和业务问题。一个业务规则定义或约束一个业务方面,该方面旨在确认业务结构或影响企业行为。约束规定一些限制或要求,它们通常是条件声明的一部分。

业务策略

业务策略是组织开发来管理其动作的规则和指南。它们定义制定决策的限制。它们是影响组织成功的所有重要问题和长期影响组织的决策的中心源和参考资料。

一个业务规则示例:定期寿险

我们来考虑与定期寿险相关的业务规则。如图 4 所示,这个案例可以根据业务功能分组为 “企业业务规则孤岛”。作为流程的一部分,这些企业业务规则孤岛会与其他孤岛交互。例如,与保险费计算策略相关的规则需要与风险评估规则交互,这是因为风险越高,保险费可能也越高;风险评估规则需要访问客户的健康状况和评分,以正确评估风险。

图 4. 定期寿险规则
定期寿险规则
定期寿险规则

业务规则的传统非 BRMS 实现

在传统的非 BRMS IT 环境中,业务规则位于 IT 部门管理和维护的各种 IT 系统应用程序中。这符合 “IT 黑匣子” 文化的要求。

图 5. 业务规则的传统实现
业务规则的传统实现
业务规则的传统实现

这种方法存在以下问题:

  • 业务逻辑与技术代码缠绕在一起。

    业务逻辑和相关策略通常使用 Java™、C++ 或类似语言实现。这样,业务逻辑就隐藏在技术代码层中,只有开发人员和 IT 社区能够理解。

    这种方法的另一个非常严重的问题是,每当发生一个技术相关更改,比如技术版本升级或其他非业务相关问题,应用程序的业务方面都有可能会受到影响。

  • 缺乏业务可见性

    业务人员难以理解用技术语言实现的业务逻辑。例如,例如,如果某位业务分析师想了解定期寿险适当性规则的当前状态,就必须咨询 IT 人员,或者参考文档资料(很可能已经过时)获取相关信息。

  • 即使实现很小的更改也需要很长的 IT 周期

    这是上述两个局限性的最终效果。业务人员感到影响他们所需的快速更改的能力受到了限制。由于业务逻辑隐藏在代码中,因此,即便是一个微小的更改(比如更改最大参保年龄),都需要一个完整的 IT 更改周期,这通常是一个非常漫长的过程。这就是我们所谓的业务中的 “胆固醇”,即导致业务堵塞的移动缓慢的机器零件。业务部门在数周或数天之后所需的功能可能需要数月时间才能实现。这些延迟冲淡了业务特性的影响,导致组织收入和市场份额损失。

在下一节中,您将了解如何使用 BRMS 解决这些问题。

使用 BRMS 管理企业规则

业务规则管理系统 (BRMS) 对这个问题提供了一种不同的解决方法。企业的业务规则被视为整个生命周期中受到管理的一种资产。这种方法采用以下策略,它们与传统方法根本不同。

  • 分离业务规则和技术代码,将业务规则放入一个中央规则存储库中。

    业务规则位于代码外部,保存在一个中央规则存储库中。这个存储库不仅允许 IT 部门访问它,还允许业务用户访问它。

    图 6. 中央业务规则存储库
    中央业务规则存储库
    中央业务规则存储库

    这个存储库向有关各方提供了所有业务规则的一个统一视图。

  • 业务团队被授权在存储库中进行更改。

    业务用户拥有访问中央业务规则存储库的访问权。他们与 IT 部门共同负责管理这些规则。业务用户被授权,允许对业务规则进行快速定期更改,以便更快地测试这些规则并将它们推向客户系统。

    WebSphere ILOG JRules 向业务用户提供了两个强大工具:

    • Rule Team Server:Rule Team Server (RTS) 提供一个基于浏览器的中央规则存储库界面。业务用户可以使用 RTS 查看、创建和修改业务规则并完成相关工件。
    • Rule Solutions for Office: Rule Solutions for Office (RSO) 是一个强大的插件,它允许业务用户在 Microsoft® Office® 文档(比如 Word 和 Excel)中编辑业务规则,并将更改发布到规则存储库。
  • 业务规则允许业务用户读取信息

    在传统解决方法中,代码中实现的业务规则是加密的,不允许业务社区读取信息。与传统方法不同,中央 BRMS 存储库中的规则使用普通语言写入表、流和简单语句中。这允许业务用户轻松阅读、理解和更改业务规则。

  • BRMS 提供业务规则治理

    流程和策略是任何治理模型的可操作核心。这些流程和策略是治理和管理 BRMS 应该遵守、应用和实施的活动。治理在不同级别上执行以下操作:

    • 定义该级别上执行的操作的流程。
    • 确保这些流程正确工作并得到适当维护。
    • 提供审计和报告决策的方法和规则执行历史记录,后者有助于分析策略和决策对业务的影响。

    图 7 描述了治理的层次结构。最高级别是公司治理,在广泛的层面上定义所有规则和策略依从性。下面是业务治理,包含保持良好的商业道德应该遵循的法律和规定。项目治理在粒度更小的级别上定义,可能包含需要治理的项目特有事项。规则治理涉及审计和验证已实现的业务规则。

    图 7. 业务规则治理步骤
    业务规则治理步骤
    业务规则治理步骤

    图 8 展示了规则开发生命周期的不同阶段(包括规则治理)。

    图 8. 规则治理生命周期
    规则治理生命周期
    规则治理生命周期

使用 BRMS 管理规则的主要好处

大多数商业组织都面临巨大的压力,需要处理加速的业务周期。组织成功与否通常取决于是否能够快速响应当今不断变化的复杂市场和监管氛围。如您所见,越来越多的业务逻辑被外化和集中化,同时也更易于管理。向业务用户提供的规则可见性支持他们快速进行更改,不必受制于 IT 周期的缓慢循环。最终结果是业务敏捷性增加,这允许企业快速响应市场动态,在客户最需要的时候向他们提供支持,这有助于企业发展壮大并保持领先。

图 9 展示了 BRMS 的 3 个关键特征:外化、可见性和集中化,以及规则治理如何促进企业敏捷性。

图 9. 规则治理和敏捷性
规则治理和敏捷性
规则治理和敏捷性

BRMS 和传统规则实现的比较

我们已经讨论了使用 BRMS 的主要优势,但是如果您长期从事 IT 方面的工作,那么您应该知道如何分辨宣传和现实。您大脑中的怀疑细胞可能在说:“嗯,这听起来太好了,不像是真的。这太抽象了,一点都不具体。给我展示一个真实案例。” 这个要求完全合理!在本节中,我们将检查一些业务规则样例,展示使用传统语言(比如 Java)实现业务规则时的样子,并将它与 BRMS 实现相比较。

样例规则选自我们的定期寿险示例。

在图 10 和 11 中,您可以看到一个简单的年龄相关规则实现。

图 10. Java 实现示例 1
Java 实现示例 1
Java 实现示例 1
图 11. BRMS 实现示例 1
BRMS 实现示例 1
BRMS 实现示例 1

在图 12 和 13 中,您可以看到一个更复杂的规则实现,设计年龄、风险和保险金额。

图 12. Java 实现示例 2
Java 实现示例 2
Java 实现示例 2
图 13. BRMS 实现示例 2
BRMS 实现示例 2
BRMS 实现示例 2

从上面的示例可以看出,BRMS 实现更简单,更容易被业务用户理解。

现在我们来看一个决策表实现。下面是一个健康风险状况评分规则的传统实现,它使用了一个加密文件。如您所见,这个文件是不可读的,这使得维护工作变得非常困难。

图 14. 平面文件实现示例
平面文件实现示例
平面文件实现示例

在 BRMS 中,上面的平面文件可以转换为一个如图 15 所示的决策表。如您所见,这个表更容易被业务用户理解、阅读和更新。

图 15. 决策表中的健康状况评分规则
决策表中的健康状况评分规则
决策表中的健康状况评分规则

这些示例展示了 BRMS 提高了业务领域中的可见性、简单性和敏捷性。

结束语

在本文中,您看到了传统的业务规则实现如何拖累业务并增加 IT 和业务之间的隔阂。您查看了使用 BRMS 管理企业业务规则如何促进 IT 和业务之间的协作,以及如何支持业务用户查看、理解和修改业务规则。这种解决方法允许向客户快速发布业务规则更改,帮助组织提高其敏捷性。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=777050
ArticleTitle=企业业务规则的 “胆固醇” 正在堵塞您的业务 “动脉” 吗?
publish-date=11282011