BPM 观点:评估 BPM 应用程序:BPM 设计评审和魔方

在这一期的专栏中,我将重点介绍执行 BPM 设计评审的目标,实现高效评审的关键准备步骤,并概述可作为 BPM 解决方案的一部分访问的关键维度。我将介绍进行 BPM 评审的基本条款,并提供一些关于该过程中客户应关注哪些领域的建议。此外,我们还将介绍 IBM BPM 回放方法,因为我相信设计评审策略与 IBM® 回放方法的融合是开发最优 BPM 解决方案的关键。所有这一切与魔方又有什么关系呢?请阅读本文寻找答案! 本文来自于 IBM Business Process Management Journal 中文版

Scott Simmons, 执行 IT 架构师, IBM

Scott Simmons 是 IBM Worldwide Banking Center of Excellence 的首席银行解决方案架构师。在供职于 Banking Center of Excellence 之前,Scott 曾经是 Worldwide SOA Technical Architecture 团队的首席架构师,是全球 50 多个 IBM SOA 架构师的技术领导者。Scott 既是 IBM 认证的高级 IT 架构师,也是 Open Group 的总 IT 架构师。Scott 擅长于为客户和合作伙伴设计、开发及实现 SOA 体系架构,他还是一个认证的 SOA 解决方案设计师。Scott 在很多杂志上发表过文章,包括 WebSphere Developer Technical Journal、Web Services Journal 和 WebSphere Journal。在 IBM 工作之前,Scott 曾经是 Chief Technology Office 的首席架构师,在 Peregrine/Extricity 担任技术解决方案主管。Scott 在集成、消息架构以及采用 Vitria、Illustra/Informix 和 Sybase 的数据架构设计/部署方面具有广泛的经验。



2013 年 11 月 14 日

简介

Rubik's Cube我很清楚你们想说什么 -- BPM 评审和魔方? 接下来会讨论什么,PacMan 还是 Facebook?您肯定会问 “Scott,BPM 设计评审和魔方有什么关系?” 好吧,让我先来介绍一些背景知吧。我使用 BPM 技术大约有 15 年了,得出这样一个结论,评审 BPM 应用程序类似于破解魔方问题。BPM 解决方案通过大量模式和应用程序类型呈现自己。更重要的是,给定的 BPM 解决方案通常呈现多个维度,甚至在单个应用程序中也是如此。当您评审一个 BPM 解决方案时,必须考虑到所有维度,并确保它们彼此能适当地结合起来。类似地,破解魔方是为了使立方体的各个面上具有相同的颜色。所以说,BPM 设计评审和魔方之间有一定的关系,都需要采用一项技术,作为端到端流程的一部分评估多个维度。

去年,一个客户曾要求我开发一个 BPM 评审流程来支持他们的开发工作。最初,这似乎只是一个简单的运用,然而,当进一步深入这项工作时,我才意识到这比我最初想象的要困难得多,设计一个 BPM 评审流程的复杂性涉及到一个 BPM 应用程序包含或显示的多个方面,并且需要评估每个领域,以便开发优化改进解决方案的方法。

现在,让我来回答您关于 BPM 设计评审和 魔方之间关系的问题:在 BPM 中(关于破解魔方),您拥有多个维度或颜色,需要对齐才能 “满足” 需求,需要以正确的次序处理这些维度问题才能评审一个 BPM 解决方案。

这些 BPM 应用程序的一个关键宗旨是,需要结合多个 BPM 模式和应用程序类型来制定一个完整的 BPM 战略。这些模式和应用程序类型范围涉及到直通式流程、专用流程、以规则为中心的模式和传统工作流。所有这些模式都会利用许多不同因素;结果是,当我们评审 BPM 应用程序以及这些变体中的因素时,需要有足够的灵活性,在本文中讨论 BPM 设计审查时,我将采用一个得到广泛应用的方法来介绍多个特性(魔方的不同颜色),以便提供一组指导方针,让读者可以根据自己的需要使用适当的评审技术。

在本专栏中,我将介绍一个根据一般法则进行 BPM 设计评审的方法,以及一个用于多个战略客户的方法。我需要声明的是,每个组织都各不相同,因此您可能需要为您的组织定制这些技术。


设计评审的目的和目标:不仅仅是排列颜色

查看图 1(通常称为 “婚礼蛋糕” 或 SOA 层次图),很明显地可以看出,流程应用程序并不是独立存在的。业务流程应用程序提供客户应用程序(比如,用户界面)和潜在业务以及技术服务之间的关键层。BPM 通常包含多个业务和技术组件的 “编制”,以便提供组合业务服务,这通常需要状态管理功能,尽管简单 BPM 应用程序可能只能反映传统工作流,比如自动化人工任务。除了编制服务之外,BPM 应用程序还需要与横切关注点交互,比如,集成、非功能性需求、数据基础架构和治理。这恰恰就是为什么进行 BPM 评审需要的不仅仅是 “排列颜色” 的原因,因为评审非常复杂,必须处理大量不同的甚至有时相互冲突的维度。此外,设计评审通常需要多个团体的参与,这些团队中有业务方面的团队,也有技术方面的团队,他们需要确保 BPM 应用程序设计和开发中业务和 IT 之间的一致性。

图 1. SOA 层
SOA 层

或许,最好先从定义 BPM 设计评审关键目标开始。根据我的经验,该目标是:

  • 确认业务和 IT 之间的设计假设和需求。
  • 确保业务和 IT 涉众与范围和需求同步。
  • 促进协同开发方法。
  • 加速开发
  • 最重要的是,在部署之前减少异常等级。

BPM 设计评审:从哪里开始

什么是良好的 BPM 应用程序?其实这是一个很难回答的问题;没有一个简单答案。一个良好的 BPM 解决方案有诸多因素。从我的观点来看,“良好” 的关键标准是解决方案满足业务用户预期的程度。这构成了参与设计评审过程的业务涉众的需求。尽管可能有其他很多技术评审,但对于确保解决方案与业务涉众意图匹配而言,业务涉众参与设计评审是必不可少的。要成功使用 BPM,业务和 IT 之间的协作至关重要。

我们就如何进行设计评审设置了一些基本方针。成功进行设计评审的基本原则非常简单:

  • 准备 … 准备 … 还是准备!
  • 确保所有关键业务和 IT 涉众参与。如果不能确保此项,请重新制定评审计划。
  • 尽早地经常计划和执行设计评审。
  • 使用回放作为关键技术,确保 BPM 评审。
  • 继续完善评审流程并对您的组织进行调整。
  • 提前计划和发布评审会议议程并确保参与者理解其目标和目的。
  • 请勿批评、建议。确保团队摒弃自我意识!

最重要的就是 “准备...准备...再准备”。我相信一句谚语 “没有计划注定会失败”。在设计评审执行过程中,这表现得非常明显,因为评审通常需要一定时间和多个角色的参与才能确保召开一次高效会议。如果没有计划,支持者将无法参与,而且评审流程也无法交付预期的结果。评审流程是一个宝贵的实践,由参与者进行评审至关重要。

因此,要为评审准备哪些关键步骤?

  • 首先,起草和发布评审会议议程非常重要。一个议程通常包括以下主题:
    • 评审议程和目的简介。
    • 业务涉众或者需求和进展的流程所有者进行快速简介。
    • 项目经理进行更新或开发领先的发展计划。
    • 适用于 IBM 解决方案的重点领域的描述,比如流程模型/设计、基础架构、集成、用户界面,等等。

    典型评审会议通常需要 2-3 小时,具体取决于参与者的计划。尽管简短的评审会议可能适用于较小的应用程序,但我们发现 2 至 3 个小时的会议效果最好。别忘了在较长的会议中安排一次中场休息。

  • 其次,评审领导者需要确保所有需求准备就绪。逻辑需求包括安排一个适当的场所,有足够的位置供所有参与者使用,以及提供公告板、网络接入、投影仪等必须设备和其他会议所需材料。
  • 第三,开发团队领导者应该在会议开始之前收集和分发评审的关键工件。这些工件通常包括业务需求、处理设计图表、数据模型、用户界面实体模型以及模具中生成的流程文档(如果有的话)。 IBM Process Center 可生成流程应用程序的详情报告,应该在会议之前分发这些材料,注意参与者就可以评审这些工件,并准备相关问题,以便支持评审会议。
  • 第四,适当选择参与者来参加评审会议也非常重要,而且往往具有挑战性。我们在设计一个评审时,对于需要多少人参与并没有固定数字。即便如此,我们仍然发现参与者超过 10 个时通常容易导致分心。选择参与者的关键因素是确定每个参与者能够带来价值。此外,选择潜在参与者通常由组织标准决定。如果所有因素都一样,我们会发现作为整个评审会议的一部分需要满足一些关键角色:
    • 会议主持人
    • 关键利益涉众,包括流程所有者、业务涉众或最终用户、中小型企业和关键项目赞助商
    • 记录人员或书记员
    • 项目领导或项目经理
    • 企业架构师
    • 开发或技术经理
    • 流程或规则架构师
    • 适当的开发资源(假设它们向该流程提供价值)

    该领域的关键成功因素是(1)确保没有不相关的人参与会议(2)适当代表关键业务和技术利益涉众。如果有 BPM Center of Excellence,最好让其代表也参与此次会议(特别在项目有策略性的或跨组织的需求/问题时)。


BPM 设计评审指南:破解魔方的规则

在我讨论 BPM 设计评审方法之前,列出一些通用原则会很有用:

  • 不是每个项目都需要详细评审;如果您向尝试的话,该尝试可能会压垮您和您的团队。
  • 这有很多不同类型的 BPM 评审,具体取决于解决方案实现,比如 IBM BPM Standard、IBM BPM Advanced、混合解决方案(比如,Operational Decision Manager/BPM 解决方案)。
  • 评审程序和流程因受众 不同而不同(比如,技术和业务受众)。
  • 评审应该持续进行。多个评审会议至关重要。
  • 评审流程应该提供一致并且详细的步骤以供优化。
  • 评审从一开始就涉及到业务涉众,业务和 IT 协作和对齐对于 BPM 成功来说是必需的。
  • 最后可能也是最重要的是,进行 BPM 设计评审没有什么魔法公式。我将介绍基本目标和指导方针,但您需要根据您的组织和场景来确定如何定制和调整这些目标和方针。

尽管还有其他一些指导方针,但是简单地遵循以上几点就可以有助您确保 BPM 设计评审是有建设性且有价值的练习,这会产生更为优化的 BPM 解决方案部署。


回放:集中回放和 BPM 设计评审

尽管可能需要独立执行 BPM 设计评审,但我们发现大多数组织将 IBM BPM 回放与其 BPM 设计评审相结合。关于回放,我想要指出的一个关键点是,与普遍情况相反,回放不应该是表演秀会议,而应该是关键利益涉众进行的交互式会议,随着时间的推移,对解决方案进行评审并评估功能性。通过将关键 BPM 关注领域评审与回放会议相结合,组织会获得更高级别的个人回放会议结构。

我强烈推荐 IBM 红皮书 Scaling BPM Adoption: From Project to Program with IBM Business Process Manager,您可以通过它了解关于回放方法的更多信息。在本期专栏文章中,我简要概述了回放方法和方法论。图 2 描述了 BPM 开发过程中的基本步骤。正如您所看到的,有 4 个关键回放阶段:Playback 0、Playback 1、Playback 2 和 Playback 3。每个阶段通常包含多个重复的回放会议,确保特定阶段目标和目的的完成。图 2 还展示了每个开发阶段通常涉及的关键角色,以及每个回放阶段的相关交付成果。

图 2. IBM BPM 回放方法
IBM BPM 回放方法

我们通常听到的一个问题是 “多少个回放,多久一次?” 回放的数量和频率由多个因素决定,比如应用程序的战略重要性、解决方案复杂性、BPM 成熟度以及业务和 IT 涉众的总体建议。我们发现这在各个组织中是各不相同的,但对于回放计划来说,有一组指导方针是一个成功 BPM 策略的基础,有助于使回放和相关 BPM 评审流程保持一致性。

简要总结 4 个回放阶段非常有用。以下简单列出的几点摘自 红皮书

Playback 0

  • 关注点:高级流程流(需求定义和流程发现)
  • 目标:
    • 关键业务流程发现和定义
    • 定义实现范围和项目计划
    • 异常、KPI 和赞助商指标的对齐
    • 传输上下文以及从分析到开发的责任
  • 交付成果:
    • 一个可执行业务流程定义(BPD)
    • 一个参与者和用户组模型(例如,泳道线/角色)
    • 使用 BPM 变量类型的基本数据模型
    • 实物模型报告已演示可视性、分析和控制
  • 范围之外
    • 用户界面实现(使用存根或实物模型)
    • 流程活动实现(使用存根或实物模型)

Playback 1

  • 关注点:用户界面定义和实现
  • 目标:
    • BPM 用户界面实现
    • 扩展数据模型以支持用户界面和决策
    • 定义人工任务、专用接口和报告、仪表板和记分牌,以支持可视性和控制。
  • 交付成果:
    • 用户界面实现
      • 确认定义,以确保和维护数据和决策完整性
      • 外观(样式、主题、标题、一致性和布局)
    • 更新流程数据模型以及通过人工任务和接口捕获的日期
  • 范围之外:
    • 集成、参考数据或系统记录的人口

Playback 2

  • 关注点:外部系统集成(应用程序、基础架构组件,比如,电子邮件和 B2B)
  • 目标:
    • 所有集成的实现和异常处理(外部集成和其他系统记录 (SOR))
    • 服务水平协议 (SLA) 的定义和接受。
    • 与外部系统所有者对齐
  • 交付成果:
    • 每个集成点所需的接口定义
    • 系统间数据转换定义
    • 通过集成进行的异常处理和错误代码发现定义
    • 确认定义,以确保和维护数据和决策完整性
  • 范围之外
    • 该解决方案不是一个完整的或具有功能的解决方案;在这一点上没有为用户准备验收测试

Playback 3

  • 关注点:端到端解决方案的整合和终结
  • 目标:
    • 完成整合和终结该解决方案的细节,比如流程自动化、用户界面和集成
    • 充分可部署且可测试解决方案的提交,该解决方案为用户准备了验收测试
    • 关键点:该回放不应该向这个解决方案引入任何新功能,重点是严格限制完整性、细化和稳定性。
  • 交付成果:
    • 为用户验收测试环境准备的最终用户解决方案
    • 端到端解决方案所需的必要功能的实现
    • 确保最终用户、管理员和系统级开发人员了解该解决方案的文档(BPM 产品中除默认文档之外的文档)
    • 所有推迟到项目下一版的功能的描述和优先次序(新特征/功能的 “停车场”)。

设计评审指南和关注领域:颜色对齐

现在,我们来看看业务流程评审的关键关注领域。我认为这些是形成 “良好” BPM 的关键因素。从破解魔方的角度来看,这些领域代表立方体的各个面,没有哪个颜色会比其他颜色更重要,所有颜色都需要排列整齐,迷局才能破解。我将以类似的方法来处理各个关注领域或者维度:

  • 指定应该评审的维度的关键方面
  • 关于该维度,要提出的关键问题
  • 定义最佳实践,我们看到的成功解决方案就是根据这些实践而构建的
  • 评审与该维度相关的常见反模式。

重要性不分先后,在 BPM 设计评审中要评估的关键因素包括:

  • 通用 BPM 解决方案设计和实现
  • 流程建模和设计
  • 流程数据和信息建模
  • 决策服务
  • 事件管理
  • 集成服务和界面
  • 用户界面设计和开发
  • 架构方面
  • 基础架构和部署因素
  • 治理方面

主要注意的是很多因素并不是可见的(需要确定一些尖锐的问题);然而,如果在开发和设计早期没有满足一些因素,那么从长远来看,可能会带来一些挑战。尽管这不仅仅是一个 BPM 问题,BPM 应用程序通常面向业务客户,这意味着影响往往更明显,会导致对开发团队造成更多的负面影响。最后,在评审这 10 个领域之前,有一点非常重要需要注意:作为整体解决方案的一部进行分析时,基础架构决策实际上可能制定一个反模式作为 “可接受的” 选项(尽管可能不是最佳选项)。

通用解决方案设计和实现

该领域主要关注业务架构方面、项目管理和工具选择。

标准和关注领域

  • 业务和 IT、业务参与以及业务架构的战略一致性
  • 项目管理,包括回放的使用、评审会议和连续性活动
  • 根据需要选择产品和工具
  • “敏捷 BPM” 技术,包括蓝图绘制、流程发现、回放、发现研讨会和敏捷性开发

关键问题

  • 参与设计流程的业务用户有哪些?
  • 是否从业务中指定了流程所有者?如果没有,计划何时指定?
  • 是否使用适当缓解措施识别了项目中的所有关键风险和挑战?
  • 如何优化下一个应用程序版本?到目前为止学习了哪些课程?
  • 整个项目的时间表是什么?如果 BPM 应用程序已经完成,该流程需要多长时间(人工日)才能实现?
  • 团队如何估计项目范围?是可行项目吗?
  • 项目中的关键风险和挑战是什么?
  • 计划实现整个业务场景?如果不是,会省略哪一部分?为什么?准备超原计划实现吗?
  • 为什么您选择使用特定开发工具和方法,比如 BPM Standard 与 BPM Advanced?
  • 如何使用回放?回放频率是多少?通常会邀请谁来参加回放会议?
  • 采纳的是一个敏捷 BPM 方法吗?如果是,使用的是哪个组件(蓝图绘制、流程发现、回放、发现研讨会、面向敏捷的开发方法)?

最佳实践

  • 协作以及 IT 和业务对齐至关重要,必须持续且积极主动。
  • 在 BMP 开发中将执行流程发现作为第一步。
  • 流程所有权是必需的,如果没有流程所有者,则会造成混乱。
  • 定义和记录项目范围对于确保对齐以及在预算范围内按时完成任务非常重要。
  • 选择适当的工具(BPM Standard 与 BPM Advanced)。
  • 使用 IBM Operational Decision Management 支持企业级决策服务。
  • 远离瀑布式方法,该方法会导致生成非最优结果。
  • 敏捷 BPM 加速解决方案交付。

常见反模式

  • 缺乏业务参与或对齐。
  • 没有流程所有者。
  • 评审不频繁或不一致。
  • 没有考虑外部项目依赖性
  • 没有风险分析或者挑战和依赖性识别。
  • 项目范围太大(或者,更糟糕的是未定义范围)。
  • 选择错误产品或工具进行开发。

流程建模和设计

该领域关注解决方案的流程发现、建模和设计方面,重点是 BPMN 解决方案设计和协作发现以及建模。

标准和关注领域

  • 流程发现
  • 流程建模
  • 流程设计
  • 流程监控
  • 流程角色和泳道
  • BPM 解决方案建模中的最佳实践

关键问题

  • 流程发现如何完成以及企业如何参与?
  • 每天有多少个流程实例?多少个用户或消费者?多少个并发用户?最坏的情况是什么?
  • 平均流程持续时间是多少(最大值和最小值)?
  • 是否使用(正式)业务建模?Visio、Blueworks Live 还是 WebSphere Business Modeler?
  • 是否在模型中使用了模拟分析?是否在模拟分析后识别如何优化流程?
  • 团队是否使用协作式方法来开发业务模型?
  • 业务发现和业务设计如何保持一致?例如,Process Designer 是否订购了 Blueworks Live?
  • 流程如何启动(例如,预定、人工或事件触发)?
  • BPM 和 SOA 以及集成功能之间的流程维护是否完全分离?
  • 如何为技术和业务异常提供异常管理?
  • 常见功能如何反映在解决方案中?是通过一个集中维护子流程或功能提供的吗?
  • 是否遵循良好 BPM 编码和设计实践?
  • 是否测量或监控业务流程(例如,仪表板)?
  • 解决方案中的关键角色是什么?这些角色是否直接映射到了流程的泳道中?

最佳实践

  • 流程发现是 BPM 设计中一个关键且独特的步骤。
  • BPM 设计的模式应是自顶而下和中间会合(而不是自底而上的)。
  • 流程分解和粒度是开发/维护的关键。
  • 确保设计流程随时间提供优化和自适应。
  • 复杂性与可维护性成反比(KISS 原则)。
  • 关注模块性(例如,嵌套流程、外观设计模式和基于组件的)。
  • 标准化流程和活动,以便尽量扩展和提高灵活性。
  • 删除没有价值的活动。
  • 通过并行处理压缩时间。
  • 尽可能自动化人工步骤。
  • 使用可能支持重用和最大化扩展性的工具包。
  • 建模角色和泳道以指定任务责任。
  • 在流程早期根据建立的惯例建模异常管理。
  • 执行最佳 JavaScript 实践(参考 JavaScript 最佳实践
  • 执行最佳命名标准实践,请参阅 Blueworks Live BPM 社区中的 Best Practices Recommendations

常见反模式

  • 无(或最小)流程发现。
  • 发现和设计受现有 BPM 实现与构建最佳流程实现的约束。
  • 流程设计完全由 IT 完成(通常基于一个业务需求文档)。
  • 最小的或不存在的命名标准。
  • BPM 设计反映了 “快乐路径”,对异常处理的关注非常有限。
  • 缺乏指标或监控(没有 SLA)
  • 自底而上 SOA 或基于 IT 的方法与自顶而下的方法。
  • 基础建模反模式。
  • 用户界面而非实际流程驱动设计决策。
  • 有限的流程分解(所有流程都处于第一阶段)。
  • 有限的子流程被用来模块化流程组件。
  • 里程碑仅是一两个活动(每个里程碑应有 4-7 个活动)
  • 流程活动大小和范围大幅变化。
  • 同一角色有多个活动的流程活动(例如,一个 “珍珠串” 模式)。
  • 循环回之前的步骤以重复这些活动的数据流(例如,BPM 的 Go To 命令)。
  • 执行不力的并行网关导致出现竞争条件。
  • 多系统泳道的实现。
  • 缺少关键 BPM 角色和泳道定义的识别和确认。

流程数据和信息建模

该领域关注特定 BPM 应用程序中数据组件的设计和运行时间行为。

标准和关注领域

  • 数据建模定义,比如关键实体
  • 一致的数据管理和使用,比如流程数据以及源数据和目标数据的一致性
  • 一致的变量范围(例如,输入/输出变量与私有变量)

关键问题

  • 流程输入和输出内容是什么?
  • 信息到达时会导致流程实例(重)启动吗?
  • 流程将使用什么类型的信息?结构化数据、非结构化数据、具体文档,等等。
  • 是否使用自定义数据类型来支持扩展的数据类型,比如客户、地址以及其他混合数据类型?
  • 是否定义了数据对象来支持流程监控和管理需求?
  • 流程数据存储在哪里?BPM 应用程序如何与 “记录来源 (SOR)” 相连接?
  • 流程中如何进行数据质量管理?
  • 流程只传递活动所需的信息吗?
  • 对类似流程中的实体和属性直观性以及一致性需要命名以及进行数据分类吗?
  • 文档管理是解决方案必需的一个方面吗?如果是,在哪里通过什么机制(例如,CMIS)存储内容?

最佳实践

  • 您应该使用不同数据模型满足不同的需求。
  • 确保 BPM 应用程序中数据设计(名称和数据类型)的一致性。
  • 在输入源处管理数据质量。确认规则对此十分重要。
  • “如果不能度量它,则意味着不能对其进行管理”。需要定义 KPI 和 SLA,而且它们应在相应的范围内。
  • 使用视图来设计数据对象有助于提高性能和重用性。
  • 保护内部和外部数据(支持私有变量 “隐藏”)。
  • 仅传递需要的数据,不能多也不能少。
  • 如果需要集成内容存储库,那么可以使用标准集成模式(比如 CMI)来完成。

常见反模式

  • 基于 XML Schema 或模式设计数据对象并根据实际流程需求来定义数据对象。
  • 流程应用程序内以及流程应用程序之间的数据对象冗余与不一致性。
  • 数据对象中缺乏标准和一致性,比如命名、类型分配和使用。
  • 将不必要的数据传递给活动。
  • 应用程序中的不一致对象和冗余对象。
  • 将大量数据对象传递给子流程和活动,或者传递到它们之间。
  • 没有设计和开发数据对象来支持流程监控。
  • 将集成定制到文档存储库中。

决策服务

该领域重点关注 BPM 应用程序中决策服务(业务规则)的集成。

标准和关注领域

  • 规则设计
  • 规则语义和商务词汇
  • 常用规则范围和可重用性
  • 规则治理和生命周期问题
  • 注意:IBM Operational Decision Manager (ODM) 应用程序评审不再文本讨论范围之内

关键问题

  • 业务流程中有业务规则吗?有多少个?是什么类型的规则(数据检查、验证、复杂的决策,等等)?
  • 规则是如何实现的(在代码中,在 BPM 规则中或者在 BPMS 中,等等)?
  • 如果您与一个外部 BRMS 解决方案相连接,比如 IBM ODM,该如何完成此操作?
  • 业务用户需要访问和更新业务规则权限吗?
  • 其他流程应用程序值或外部应用程序中存在类似规则吗?
  • 如何随着时间的推移而持久化存储、更改和治理规则?

最佳实践

  • 规则通常 应用于单个业务实体。
  • 标准 BPD 模式:Gateway 之前的决策任务。
  • 明确了解和实施流程规则使用实践与业务规则 (BRMS) 使用实践。
  • 使用多个决策步骤定义混合决策活动。
  • 通过 BPM 工具包管理多个流程应用程序的常见规则。

常见反模式

  • 关于规则如何实现和执行会导致使用过程中产生不一致性的限制标准。
  • 作为单独活动实现一系列决策与更多模块设计。
  • 将规则嵌入到代码中(JavaScript 或外部代码)。
  • 由于规则的复杂性、业务用户需求、治理因素或其他应用程序中类似规则的需求,BRMS 可能成为一个较好的解决方案,此时可以在 BPM 应用程序中调整规则。
  • 冗余规则(在相同的应用程序和相关流程应用程序中均有)。

事件管理

该领域主要关注事件管理的 BPM 方面,特别是如何使用其他流程和其他外部代理激活流程,以及如何在内部提供事件和通知功能。

标准和关注领域

  • 事件使用
  • 事件设计
  • 事件范围
  • 注意:Review of IBM ODM 应用程序评审不在文本讨论范围之内。

关键问题

  • 应用程序中支持什么类型的事件(通知事件、特别事件、异常处理,等等)?
  • 如何并行执行事件(秘密代理(UCA)、JMS)?
  • 如何启动事件(在流程层,通过定时、计划或其他方法)
  • 事件执行是否按照每个时期的平均和最大事件数进行定义,以支持需求调整?
  • 对于同类事件,是使用新数据模型,还是根据复杂类型开发可重用模型?
  • 应用程序支持外部事件吗(入站或出站)?
  • 活动范围定义良好吗(例如,已经定义了源和目标)?

最佳实践

  • 实践的实用性。记住 JMS 用于支持事件交互,因而需要考虑性能因素。
  • 事件可扩展性需求应该考虑解决方案大小调整确定因素。
  • 在整个 SDLC 中进行测试所有关键事件条件。

常见反模式

  • 流程之间以及相同流程中的冗余事件函数。
  • 缺乏设计或没有模块化事件数据模型。
  • 由于缺乏事件特性定义而导致出现大小调整或扩展问题,进而影响大小调整。
  • 不良事件设计可能导致 “事件风暴” 和无限循环模式。
  • 给定流程或活动的多个入站事件(不止 3 或 4 个事件)。

集成服务或界面

该领域主要关注 BPM 应用程序和外部系统之间的相互作用,比如数据库、应用程序、非 BPM 技术,等等。

标准和关注领域

  • SOA 或技术实现方面
  • 标准集成技术(比如,适配器)和模式的使用
  • 工具包和 Advanced Integration Services (AIS) 的使用

关键问题

  • 与外部数据库或应用程序交互吗?如果交互,那么是只读交互还是读取-更新交互?
  • 与合作伙伴系统或者外部数据提要交互吗?如果交互,如何实现?交互是只读的还是读取-更新的?
  • 是否通过与外部供应商建立了 SLA 来确保解决方案的可行性?
  • 如何访问外部服务?直接耦合、ESB,还是定制?
  • 准备使用 BPM Advanced 还是其他技术来支持集成需求?
  • 集成方法是什么,基于标准的方法还是其他方法?
  • 是否使用数据规范化从企业应用程序中访问业务对象?
  • 使用的关键集成标准是什么(Web 服务,REST 还是其他)?
  • 需要跨多个事务支持事务范围吗?如果需要,如何实现?
  • 使用 BPM 工具包支持常见集成需求?

最佳实践

  • 以模块化方式设计集成(外观设计模式、模式和嵌套流程)导致生成一个更为灵活的解决方案。
  • 对于数据包集成和定制集成,需要使用 ESB 支持信息隐藏,并进行常见变换。
  • 使用外观设计模式支持高可维护性。不用对端点进行硬编码。
  • 管理事务范围的需求是使用 BPM Advanced 进行管理的,或者确保事务一致性是由执行更新活动的服务容器进行管理的。
  • 将常见集成服务分解到工具包;重用对于维护来说非常关键。

常见反模式

  • Process Designer 中的集成实现与其他工具。
  • 对于外部系统来说,只有有限的 IT 中小企业和外部系统基础架构参与。
  • 对于外部系统来说,缺少 SLA 知识。
  • 缺少外部系统界面设计(有限的标准使用,多个数据模型,等等)。
  • 冗余集成服务导致出现管理问题。
  • 未考虑事务范围问题。
  • 竞争条件。
  • 大量 EARs/JARs 被部署到 IBM Process Server。
  • 此外,还有一些特定于 BPM Advanced 的反模式,但这些不在本文的讨论范围之内。

用户界面设计和开发

该领域重点关注解决方案的用户界面,标准、使用特征和功能性等方面。

标准和关注领域

  • 用户界面设计
  • 界面直观性和可用性
  • 界面一致性
  • 性能

关键问题

  • 团队如何设计用户界面(例如,业务用户协作,比如,回放、故事板、规范用例)?
  • 使用什么技术来开发用户界面(Coaches、eForms、HTML、Dojo、JSP、portlet、Business Space 小部件)?
  • 特定 BPM 应用程序或流程中有多少个不同 “界面” 或 Coach?
  • 用户界面和 BPM 应用程序之间的交互本质是什么?
  • 就可用性、适用性和性能而言,用户界面的测试方法是什么?
  • 就导航、字段外观和菜单格式等方面而言,用户界面中是否使用了标准?
  • 工具包是否用于管理用户界面开发常用组件的重用?
  • 界面是否使用适当的标准和最佳实践进行设计(Web 应用程序指南,可访问性标准,等等)?

最佳实践

  • 让服务器工作(使用服务器端脚本、存储程序等等)。不要使用户界面过于复杂化,简单最好!
  • 基础 Coach 提供了良好的开端;成功的 BPM 实践者通常使用基础 Coach 实现原型化和最初回放,这些最初界面是通过开发来扩展的。
  • 使用标准 Dojo 小部件增强用户界面。
  • 将常用 UI 组件分解到工具包,并相应地重用这些组件。
  • 使用文档记录的方法来集成外部门户,比如 WebSphere Portal。
  • 关注可访问性标准。参考 Web 检查清单
  • UI 开发关键用户界面指南和标准的指定,参考 设计原理

常见反模式

  • UI 设计中缺乏业务关注或参与,结果生成的是技术 UI 而非业务 UI。
  • BPM 应用程序中和应用程序之间缺乏用户界面标准。
  • 应用程序中和应用程序之间的用户界面一致性有限。
  • 根据当前现有解决方案设计过于复杂的界面(例如,将多页面形式重新构建到一个用户界面中)。
  • 冗余 UI 组件与创建可共享组件,以及适当重用。
  • 由于过于复杂或 UI 较大而导致 BPM 启动性能较差。
  • 界面设计受当前流程行为和用户视角的约束。

架构方面

该领域重点关注基础架构方面,比如整体解决方案基础架构和非功能性需求,比如,可用性、可扩展性、安全性,等等。

标准和关注领域

  • 架构设计
  • 非功能性需求 (NFR),比如,可扩展性、可用性、安全性、可移植性和可靠性。
  • 优化可用性、可扩展性、可维护性、法律和监管

关键问题

  • 该解决方案如何与其他相关外部组件进行良好交互?
  • 就 NFR 决策而言,是否考虑了该解决方案的所有组件?
  • 如何在应用程序层定义可用性和 SLA?该定义是否考虑了外部系统和组件?
  • 如果流程中出现问题的话该怎么做(可恢复性)?
  • 是否定义了性能特性?如何将性能分析和测试构建到项目时间线?
  • 所有必要法律和监管问题是否得到解决?这对于管制行业尤为重要。
  • 是否提供应用程序安全审计?作为一个解决方案拓扑(例如,DMZ 限制)解决方案是否根据内部和外部客户定义了关键安全需求?
  • 如何管理用户认证(LDAP 或基于 BPM)?
  • 如何设计解决方案进展和灵活性(例如,松耦合)?

最佳实践

  • 在设计早期定义和重访非功能性需求 (NFR)。
  • 利用技术来支持快速的重构和灵活的修改,比如,问题分离、敏捷 BPM 和松耦合。
  • 良好的架构设计通常会产生良好的性能。
  • 使用 LDAP 作为单个集中的用户管理授权。不要尝试构建自定义的概要分析或认证服务,除非必须定义。
  • 在物理拓扑以及逻辑架构中设计变更和灵活性。

常见反模式

  • NFR 因素是次要的(或不存在)。
  • 有限的恢复性需求定义和相关功能需要缓和。
  • 可用性和 SLA 没有有效定义或作用域。
  • 有限的可扩展性定义导致性能不足,从而无法进行后续部署。
  • 安全性和权利是一项补救措施(不支持 IT 安全性)。
  • 遵循设计架构的设计目标(比如松耦合)有限,导致生成不灵活的解决方案。

基础架构和部署因素

该领域主要关注 BPM 解决方案的实际平台和部署方面。

标准和关注领域

  • 开发测试和运行时拓扑定义
  • 性能和负载测试
  • 操作管理
  • 源代码管理

关键问题

  • 开发、测试和生产环境的 IT 配置是什么(平台、机器数量、群集、虚拟化、网络负载、HTTP 服务器,等等)?
  • 什么会影响平台和操作系统的选择?
  • CDR:高可用性和灾难恢复环境中实现 HA 和 DR?
  • 项目计划是一个完整的端到端性能压力测试吗?
  • 如何部署新版 BPM 软件?
  • 如何部署新版 BPM 应用程序解决方案?
  • 管理和监控 BPM 应用程序的流程是什么?有评估相关数据库和应用程序服务器的流程吗?
  • 如何完成大小调整?内部专家还是外部专家协助?对大小调整是否正确有信心吗? 注意:大小调整是一个关键部署因素,但不在文本的讨论范围之内。应当注意的是,尽管几乎所有组织都进行了大小调整,但通常都是基于不准确的假设进行的,没有考虑到潜在的可伸缩性挑战。

最佳实践

  • 使用标准部署模式根据需要进行部署(比如,Gold Topology)。
  • 整合 Process Center 和 Process Server 以维护可扩展性、故障恢复、高可用性和冗余支持
  • 作为整体操作管理的一部分,评估和评价共享服务、外部应用程序和数据库 SLA。
  • 优化 Process Server 数据库和应用程序服务器,并随着时间的推移进行维护。
  • IT 开发人员使用 UTE(单元测试环境)进行单元测试(而不是 Process Center)。

常见反模式

  • 有限的开发、测试和生产拓扑定义。
  • 缺乏端到端的系统测试。
  • 与外部系统利益涉众缺少协作,无法确保端到端的操作管理和及时的根源问题诊断。
  • 没有考虑网络延迟(特别是在高分布式实现中)。
  • 在一个未进行良好大小调的环境中部署和安装。

治理方面

该领域主要关注关键 BPM 治理方面。尽管与 SOA 治理相关,但该领域应该与 SOA 治理分开评审。

标准和关注领域

  • 治理标准、策略和方法
  • Center of Excellence 或 Center of Competency
  • 资产管理、工具包、共享服务和资产重用
  • SOA 治理交互(例如,Service Registry)
  • BPM 开发、SDLC 促销管理和变更管理
  • 流程优化和评审

关键问题

  • 项目遵守组织的 BPM 治理标准、策略和方法吗?
  • 组织 BPM Center of Excellence 如何参与整个项目(如果有的话)?
  • BPM 解决方案中如何管理、跟踪和监控公共资产?
  • 流程中使用 BPM 工具包吗?为什么使用?为什么不使用?
  • 业务和技术流程和服务在何处登记或注册(例如,流程存储库或服务注册表)?
  • 如何管理服务和规则生命周期、服务流通、服务选择和版本控制?
  • 除了 Process Center 外,还有源代码管理系统吗?如果有,SCM 工具和流程库之间的同步点是什么?
  • 特定 BPM 解决方案如何进行版本控制?从操作角度如何恢复到之前的版本?
  • 从使用 BPM 技术实现流程中感知的和实际成本是什么?如何获得节约成本和价值?
  • 如何监控 BPM 流程以便进一步优化?

最佳实践

  • 实现一个 BPM Center of Excellence (CoE) 来开发和执行正规治理策略。
  • 开发和执行一个共享服务组件策略,比如,作为综合重用策略和指导方针的流程和工具包。
  • 由 CoE 形式化参流程、评审和专用项目审计。
  • 维护文档(使用案例、系统环境、架构图、操作架构和架构决策)。BPM 没有改变该需求。
  • 是否使用外部 SCM 工具开发常规使用指南并确保组件来源于 SCM。

常见反模式

  • 没有治理标准、策略和方法。
  • SOA 和 BPM 治理完全一样。
  • 缺少一个最大化重用的方法,比如,使用 BPM 工具包。
  • 共享组件没有得到积极管理和审计(例如,工具包蔓延)
  • 有限的 BPM 应用程序使用监控和有限优化流程。

执行设计评审

假设您制定了一个评审参与者可接受的议程,您会发现执行一次评审的确是一个简单的过程。我开发了一个电子表格工作产品来帮助各个组织评审和评估 BPM 产品。我故意没有在本文中对该工具进行介绍,因为它目前还是草稿格式。如果您想要使用该工具进行评审,可以直接与我联系。这个电子表格是一个不受支持的加速器,可在评审过程中为您提供帮助。

召开 BPM 设计评审会议所需的指导方针是基本要素。重要的是,会议主持人需要确保评审稳步进行,不会浪费参与者的宝贵时间。参与者通常可以发起一些与评审不是密切相关的次要话题。在这些实例中,会议主持人应该记录这些话题,以便进一步评审。此外,主持人通常充当教练和同伴角色,确保每个人都能发挥其作用,确保每个人都参与其中,确保评审提供建议和活动步骤,以创建最优的 BPM 解决方案。最后需要指出的是,主持人或评审领导者应该能够快速做出决定,准备应对意料之外的情况,但是,如果有可靠的议程、合适的参与者和有效的准备工作,这可能会是一个例外。

确定会议是否成功的关键标准是确保评审目的能够实现,并以积极的方式推进 BPM 解决方案。


最后的交付成果

我坚信一个高效的评审会议会交付一定的成果,即便该成果是一个文本文档或者一封邮件。交付成果应当作为一组活动步骤来解决潜在不足,或者根据评审过程中提出的建议优化整体解决方案。

评审会议交付成果格式由组织决定。我的很多客户从没有参与过这类设计评审,结果导致没有评审交付成果标准。在这些案例中,交付成果往往只是来自记录员的数分钟简单记录。在其他组织中,这个过程可能更为正式,需要一个标准文档来记录下一个步骤和活动。最后一点,创建会后交付成果毫无意义,除非开发团队和业务涉众提供一个流程来确保活动可在适当时间内完成。很多使用 IBM 回放方法的客户有一个捕获所需活动的机制,而且还有一个管理评审建议的流程。底线是确保评审后活动与您组织的当前设计评审流程相一致。


结束语

本文重点介绍了开发一个 BPM 设计评审方法的目的和关键指南。我试着提供一个高水平最佳实践来开发和执行成功的 BPM 设计评审。遵守 BPM 使用关键指导方针(比如,敏捷 BPM、回放使用以及符合业务和 IT 的持续 一致性)的组织会发现,BPM 评审过程很容易实现。

尽管我承认在本文中的确遗漏了评审标准,但我希望本文能够给您提供灵感,帮助您推动和实现 BPM 设计评审流程。给予 BPM 设计评审会议主持人的最后一点忠告是:理解设计软件类似于创作一首歌曲或一个艺术品。人们都不喜欢他们的作品饱遭受批评,所以要谨慎设置和建议更改。评审参与者应该尝试加入会议并从实际和经验角度提出建议。

执行设计评审的关键挑战似乎是确定要评审的关键领域。本文列出了需要评审的 10 个特定领域:

  • 一般 BPM 解决方案设计和实现
  • 流程建模和设计
  • 流程数据和信息建模
  • 决策服务
  • 事件管理
  • 集成服务和界面
  • 用户界面设计和开发
  • 架构方面
  • 基础架构和部署因素
  • 治理方面

正如我在本文开头所提到的,有许多不同类型的 BPM 应用程序和相关模式。还有众多确保业务调整和协作的要求,就其定义而言,BPM 解决方案过于复杂。但至少您不能忘记有很多方法,您会发现进行一次 BPM 评审就像是在破解一个魔方,尽管有很多方法,但是需要一系列精密的技术和技巧来掌握该流程,从而破解魔方!


致谢

我要向 Scaling BPM Adoption: From Project to Program with IBM Business Process Manager 一书的作者表示感谢,本文回放小节使用的资料均来自此书。这本红皮书是我在 BPM Adoption 领域找到的最好的一本读物,强烈建议大家下载一个副本认真阅读一下。

我还想要表达我对 IBM North America BPM Solution Architect 团队的感谢,感谢他们对该方法的持续使用(逐个测试通过),以及他们对我所创建的 BPM Design Review 电子表单提出的宝贵意见和建议。很高兴能与这样出色的一个团队共同工作,与他们成为合作伙伴,与领域最优秀的技术员工合作将成为一段难以忘怀的工作经历。感谢这样一群令人敬佩的人!

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=953027
ArticleTitle=BPM 观点:评估 BPM 应用程序:BPM 设计评审和魔方
publish-date=11142013