| UML软件工程组织 | |||
| |
|||
|
|||
规则架构师的角色
2008-08-07 作者：Arun Chhatpar 来源:IBM
业务规则架构师在设计组织良好、直观的业务规则模型方面扮演着重要角色，以帮助技术和业务参与者理解业务规则模型。本文讨论该角色的重要性，并使用业务规则开发生命周期来描述规则架构师在创建可靠、可扩展的业务规则实现方面的职责。 业务规则架构师的职责？正如在前一篇文章“业务规则入门简介”（请参见参考资料）中所描述的，业务规则是一种实现和强制业务策略的方法。业务规则管理 (BRM) 系统则基于业务规则来自动化和管理决策。随着 BRM 系统的日益普及，更多的企业开始大规模实现这些系统，使它们变得越来越复杂。因此前期设计非常重要。业务规则架构师是负责正确地设计这些 BRM 系统的人员。 业务规则架构师与业务所有者和 IT 人员协作以构建组织业务规则策略的整体视图。规则架构师负责将组织的业务需求转换为可靠而稳定的软件系统。规则架构师承担了通过设计和构建简单化、可重用的组件来降低创建和维护业务规则的总体成本的任务。 高效率的规则架构师的素质作为规则架构师意味着您不仅需要拥有技术技能，而且需要有效的沟通技能。我们来看看规则架构师需要具备的一些最重要的素质：
既然我们已经了解了优秀的规则架构师需要具备的素质，现在让我们看一下规则架构师在业务规则开发生命周期中的各个步骤的职责。 业务规则开发生命周期业务规则系统架构师的目标是将业务考虑从逻辑代码中分离出来，然后将它们组合到容易管理的系统中，以允许业务用户使用类似于英语的语法来创建和更新规则。与任何软件系统开发一样，业务规则系统具有已定义的生命周期。规则开发中的三个主要步骤是设计、开发和维护。让我们来了解各个步骤，以及规则架构师在每个步骤中扮演的角色。 规则架构师在业务规则开发生命周期中的第一步是设计。在设计步骤中涉及的子任务包括：
图 1 显示了设计规则的过程。 图 1. 突出显示业务规则设计过程的完整 BRM 系统体系结构
如图 1 所示，IT 人员使用 BRM 集成开发环境 (IDE) 工具来创建模板，业务用户则使用这些模板从 RMA 编写规则。规则架构师在此过程中扮演着重要角色。 在设计过程开始时，规则架构师帮助正确地确定规则。正确地确定规则有助于使不必要的规则远离规则存储库。规则架构师必须确保通过与业务用户进行大量访谈并使用一些技术（如需求收集）来捕获所有规则。架构师还可以使用像 IBM Rational® RequisitePro® 这样的工具使该过程变得简单（请参见“Rational RequisitePro 让您绝处逢生”侧栏）。 在确认后，规则架构师必须确保将规则划分到适当的类别。正确地对规则进行分类非常重要，因为分类会影响规则生命周期的所有三个步骤（设计、部署和维护）。 规则架构师然后必须使用正确的构件来定义模板。BRM 系统中的构件是什么？它们是一些原型或构建块，规则设计者可用来以逻辑形式创建规则集。BRM 工具中的构件示例包括规则集、决策表、决策树和记分卡。您应该使用规则集或决策树来定义一组规则吗？规则架构师必须决定使用哪些规则，以定义一组规则并确保使用正确的构件来定义它们。 规则架构师在设计时还必须考虑代码重用性。这里体现了架构师所掌握的技术知识的重要性。您设计的规则集必须同时具有可扩展性和可重用性。 当业务用户在 RMA 中已创建其规则后，下一个步骤是将它们与您的现有应用程序一起部署，下面将对此进行说明。 如前所述，规则架构师的视野必须能够超越当前系统。这不仅与哪些规则进入系统有关。规则架构师还必须考虑正在开发的系统如何与现有应用程序建立连接。大多数业务规则实现或者替换现有遗留应用程序，或者作为大型系统体系结构的子组件。由此类混合系统引入的复杂性使业务规则系统的集成变得更有难度。描述遗留系统与新应用程序的完整集成过程不在本文范围之内，但让我们进一步了解部署过程中涉及的一些步骤。 规则架构师必须选择目标实现的类型。使用目前的 BRM 工具可以为规则引擎使用不同的部署选项。其中的一些选项包括：
规则架构师必须定义接口来与现有的外部和遗留应用程序交互。此步骤包括将新业务规则应用程序与已经运行了一段时间的其他应用程序和企业信息系统（通常称为企业的“遗留”系统）集成。企业无法承受这些遗留系统发生任何中断。因此规则架构师必须确保新系统与现有应用程序无缝地协作。这可能涉及让您的新系统向其他应用程序公开，或实现其他系统接口来与之交互。 规则架构师现在必须部署规则引擎。 图 2 说明了 BRM 系统的规则部署过程。 图 2. 突出显示业务规则部署和与外部及遗留应用程序集成的完整 BRM 系统体系结构
图 2 显示的系统相当简单，因此不可能是现实中的案例。实际上，规则架构师在创建规则引擎和外部及遗留应用程序之间的接口方面应该非常用心。 规则架构师必须考虑规则引擎的性能，而不能让它变成您的系统整体性能的限制因素。这与在其中部署规则引擎的系统的性能不同。相反，这指的是规则引擎本身的性能，并取决于执行规则和将结果返回给调用应用程序所花费的时间量。有几个因素会对性能产生负面影响，如数据模型的设计不正确（例如，在您的数据模型中产生对多维数组的需求）。保持简单的设计和使用一维数组总是更好的做法。糟糕的接口设计、硬件限制和跨系统集成也会降低系统的整体性能。 从基础结构的角度而言，规则架构师必须促进规则存储库的正确管理。可以通过集中组织业务规则和基于任务对业务流程和组件进行建模来实现正确的管理。规则架构师必须鼓励共享基础结构和应用程序以降低成本和改进信息流。正确地管理规则存储库还可让架构师将业务规则和组件重用于新的业务领域，快速进入新市场，以及根据需要覆盖特定组件以解决新需求。 规则部署应该算作 IT 任务，业务用户不参与其中。在规则维护的最后过程中再次牵涉到规则部署，下面将对此进行说明。 规则开发生命周期中的最后过程是规则维护。业务用户与规则架构师协同工作，在持续的过程中维护规则。该过程使业务用户能够对规则进行更改，而不必请求 IT 人员提供帮助。BRM 系统的思想是为业务用户提供对业务逻辑更改的完全控制，而不必与 IT 人员协作。这里的关键之处是拥有公共规则存储库。了解规则存储库对于理解规则维护过程的必要性非常重要。存储库必须能够供各种应用程序共享和访问。图 3 帮助说明了这一共享。 图 3. BRM 系统的体系结构视图
正如您所看到的，所有三个组件（IDE、RMA 和规则引擎）使用同一个公共规则存储库。这里的理念是提供一个公共基础，并且仍然允许所有组件独立访问业务规则。因此，即使规则引擎在运行时指向相同的存储库，业务用户仍然可以对规则做出更改，并且这些更改立即被规则引擎拾取，而无需 IT 人员的干预。当然，规则架构师仍然必须管理像发布管理和版本控制这样的操作。但是，这是在理想情况下的工作方式。 规则架构师必须为业务用户提供更改规则的界面。该界面与在规则设计过程中创建的供业务用户管理和更新规则的 RMA 相同。创建的模板被打包并通常部署在应用程序服务器上，从而为业务用户提供用于管理规则的简单 Web 界面。 规则架构师必须创建版本控制策略。版本控制提供所有更改的记录。组合由业务用户做出的更改同样非常重要，这样您就可以在出现问题时回滚更改。 规则架构师还必须创建代码发布策略。虽然业务用户可能不习惯于发布管理概念，但不允许他们在任何时间做出更改。规则架构师必须执行可行的发布策略，并且必须通知业务用户遵循该策略。当策略就绪后，业务用户可以根据发布计划按需更新规则。 图 4 显示了业务用户维护规则的过程。 图 4. 突出显示使用 RMA 维护业务规则的完整 BRM 系统体系结构
就像设计和部署步骤那样，规则架构师在维护步骤中也承担特定的职责。但是在过程中的这一阶段，架构师除了确保正确地部署新规则系统并且 RMA 始终可供业务用户更改规则之外没有多少工作需要处理。 规则架构师的另一项职责是创建简单而用户友好的界面。规则开发人员通常创建 RMA 页，但架构师可以而且应当实现简单的方法来设计用户界面 (UI) 的外观。这一点再怎么强调都不过分。在我的一次工作中，某个领先的 BRM 工具几乎被完全舍弃，因为它的现成 UI 非常难以使用。因此，努力让界面保持简单。 规则架构师的工作可能听起来非常简单而直观，但它对于当今的 IT 来说很可能是极具挑战性的工作之一。 总结优秀的规则架构师必须真正充分了解业务规则领域，这不仅包括业务规则和遗留应用程序接口，还包括系统的实际内涵。他们在面对需要实现的特定系统时，会提出大量不同的解决方案，并且能够从中选择正确的方案。我希望本文能帮助您很好地了解这一富有挑战性的角色。 参考资料学习
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
