BPM 观点:评估 BPM 应用程序:BPM 设计评审和魔方2014-08-18 IBM Scott Simmons
简介

我很清楚你们想说什么 -- 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 层

或许,最好先从定义 BPM 设计评审关键目标开始。根据我的经验,该目标是:确认业务和 IT 之间的设计假设和需求。确保业务和 IT 涉众与范围和需求同步。促进协同开发方法。加速开发最重要的是,在部署之前减少异常等级。